Merge branch 'master' into add-bumpversion-support-to-helm-values

data/extract.py

@@ -2,7 +2,7 @@
 import json
 import os
 import distutils.core
-from os.path import dirname, realpath
+from os.path import basename
 
 if sys.version_info[:2] >= (3, 3):
   from importlib.machinery import SourceFileLoader
@@ -33,10 +33,8 @@ def setup():
 @mock.patch.object(setuptools, 'setup')
 @mock.patch.object(distutils.core, 'setup')
 def invoke(mock1, mock2):
-  # Inserting the parent directory of the target setup.py in Python import path:
-  sys.path.append(dirname(realpath(sys.argv[-1])))
   # This is setup.py which calls setuptools.setup
-  load_source('_target_setup_', sys.argv[-1])
+  load_source('_target_setup_', basename(sys.argv[-1]))
   # called arguments are in `mock_setup.call_args`
   call_args = mock1.call_args or mock2.call_args
   args, kwargs = call_args

docs/development/configuration.md

@@ -38,7 +38,6 @@ e.g. apply one set of labels for `backend/package.json` and a different set of l
 module.exports = {
   npmrc: '//registry.npmjs.org/:_authToken=abc123',
   baseDir: '/tmp/renovate',
-  logLevel: 'debug',
   includeForks: true,
   gradle: { enabled: false },
 };
@@ -53,6 +52,8 @@ $ node renovate --help
 To configure any `<list>` items, separate with commas.
 E.g. `renovate --labels=renovate,dependency`.
 
+To enable debug logging export `LOG_LEVEL=debug` to your environment.
+
 ### renovate.json
 
 If you add a `renovate.json` file to the root of your repository, you can use this to override default settings.

docs/development/issue-labeling.md

@@ -16,6 +16,22 @@ Most issues should have a label relating to either a platform, manager, datasour
 
 ## Label categories
 
+### Status
+
+<details>
+    <summary>Status of issue</summary>
+
+    status:requirements
+    status:blocked
+    status:ready
+    status:in-progress
+
+</details>
+
+Use these to label the status of an issue.
+For example, use `status:requirements` to mean that an issue is not yet ready for development to begin.
+All open issues should have some `status:*` label applied.
+
 ### Type of issue
 
 <details>
@@ -116,6 +132,7 @@ Apply these labels when somebody opens a `feature` type issue requesting a new d
     help wanted
     reproduced
     reproduction needed
+    duplicate
 
 </details>
 
@@ -127,6 +144,8 @@ Add the label `help wanted` to indicate that we need the original poster or some
 Add a label `reproduction needed` if nobody's reproduced it in a public repo yet and such a reproduction is necessary before further work can be done.
 Add the label `reproduced` once there is a public reproduction.
 
+Add a label `duplicate` to issues/PRs that are a duplicate of an earlier issue/PR.
+
 ### Self hosted
 
 <details>

docs/development/triage-guide.md

@@ -0,0 +1,93 @@
+# Triage guide
+
+## What is triage?
+
+Triage is basically filtering the issues/discussions, and categorizing them with the proper labels.
+
+## What a triagist is allowed to do
+
+If you've been given triage rights, you are allowed to do the following things:
+
+- Apply labels to issues
+- Close, reopen, and assign all issues and pull requests
+- Mark duplicate issues and pull requests
+- Request pull request reviews
+- Lock and unlock discussions
+- Individually convert issues to discussions
+
+**Note:** We don't use milestones or project boards.
+
+## Guidelines for triage workflow
+
+The following are guidelines as we cannot cover all situations.
+Use common sense, and just do your best, and you'll do all right.
+Don't be afraid to ask for help.
+
+### Apply labels to issues
+
+All issues should have labels attached to them.
+Read the [issue-labeling guide](https://github.com/renovatebot/renovate/blob/master/docs/development/issue-labeling.md) to get all the necessary info.
+
+In general try to make a good-faith effort to label things correctly.
+
+### Closing issues
+
+You can close a issue yourself if it's:
+
+- Spam
+- Obviously fixed
+
+For really old issues, it's probably a good idea to ask the maintainers to decide if they want to keep or close the issue.
+
+### Closing pull requests
+
+It's not very often that you'll need to close a PR, but you can certainly do it in case of spam or malicious content in the PR diff.
+
+### Reopen issues
+
+Sometimes a bug is fixed with a PR that links to a issue.
+When the PR is merged, the issue is automatically closed.
+Sometimes the bug was not really fixed, and someone says: "Hey this is still broken for me."
+In that case, re-open the issue only if it's definitely the same problem (users often associate different problems together incorrectly).
+Otherwise, ask the user to open a new issue if it seems like it is different.
+
+### Assign issues
+
+You can assign a issue to yourself, so that others know you're going to work on the issue.
+GitHub allows issues to be assigned to any project collaborator or to any non-collaborator who has created or commented on the issue, so you can also assign in either of those cases if it makes sense.
+
+### Mark duplicate issues and pull requests
+
+If you see an issue that's an obvious duplicate:
+
+1. Attach a `duplicate` label
+1. Use the "Duplicate of" functionality [GitHub docs, about duplicate issues and pull requests](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/about-duplicate-issues-and-pull-requests)
+1. Close the issue
+
+Follow the same workflow to mark duplicate PRs.
+
+### Request PR reviews
+
+You can request a review from one of the maintainers, in case this is needed to get the PR review process rolling.
+
+### Lock and unlock discussions
+
+Sometimes a discussion can go sour, like when people call each other names, or post spam, or veer off-topic.
+In those cases you can lock the discussion to prevent further escalation.
+
+### Individually convert issues to discussions
+
+Sometimes a issue that's raised at the Renovate repository is not really a bug or a feature request.
+This happens most often because a user files a bug for things that are really a misstake in the Renovate configuration.
+Those "configuration help" issues are then moved to the discussions board for further help.
+
+### Moving issues from `status:requirements` to `status:ready`
+
+One of the most important non-code contributions people can do is help features and fixes go from `status:requirements` to `status:ready`.
+We use the label `status:requirements` to mean "more information or research is needed before someone could start coding this".
+
+It can sometimes be an oversight of the maintainers, but more often it's because there are requirements or edge cases to consider and the user hasn't got an opinion or time to think about them and contribute enough.
+Sometimes it can be because there's a need for some research and "design" decisions to be made, which may require maintainers to do, but it's not high enough priority to justify the time yet.
+
+In a way `status:requirements` means "someone's going to need to put more thought into this before it can move forward to development".
+It can also mean "don't start this now because you might do something which can't be accepted into the code base".

docs/usage/configuration-options.md

@@ -85,7 +85,7 @@ Currently it is needed/supported for the `helm-requirements` manager only.
 ```json
 {
   "aliases": {
-    "stable": "https://kubernetes-charts.storage.googleapis.com/"
+    "stable": "https://charts.helm.sh/stable"
   }
 }
 ```
@@ -165,7 +165,9 @@ Example use:
 This setting is only applicable if you opt in to configure `automerge` to `true` for any of your dependencies.
 
 Automerging defaults to using Pull Requests (`automergeType="pr"`).
-In that case Renovate first creates a branch, then an associated Pull Request, and then automerges the first time it detects that the Pull Requests status checks are "green".
+In that case Renovate first creates a branch and associated Pull Request, and then automerges the PR on a subsequent run once it detects the PR's status checks are "green".
+If by the next run the PR is already behind master branch then it will be automatically rebased, because Renovate only automerges branches which are up-to-date and green.
+If Renovate is scheduled for hourly runs on the repository but commits are made every 15 minutes to the main branch, then an automerge like this will keep getting deferred with every rebase.
 
 Note: if you have no tests but still want Renovate to automerge, you need to add `"requiredStatusChecks": null` to your configuration.
 
@@ -251,7 +253,7 @@ This is an advance field and it's recommend you seek a config review before appl
 
 ## bumpVersion
 
-Currently this setting supports `helmv3`, `helm-values`, and `npm` only, so raise a feature request if you have a use for it with other package managers.
+Currently this setting supports `helmv3`, `helm-values`, `npm` and `sbt` only, so raise a feature request if you have a use for it with other package managers.
 Its purpose is if you want Renovate to update the `version` field within your file's `package.json` any time it updates dependencies within.
 Usually this is for automatic release purposes, so that you don't need to add another step after Renovate before you can release a new version.
 

docs/usage/docker.md

@@ -165,6 +165,11 @@ If you want Renovate to commit directly to your base branch without opening a PR
 
 ### Registry authentication
 
+There are many different registries, and many ways to authenticate to those registries.
+We will explain how to authenticate for the most common registries.
+
+#### DockerHub
+
 Here is an example of configuring a default Docker username/password in `config.js`.
 The Docker Hub password is stored in a process environment variable.
 
@@ -182,6 +187,8 @@ module.exports = {
 
 You can add additional host rules, read the [hostrules documentation](https://docs.renovatebot.com/configuration-options/#hostrules) for more information.
 
+#### Self-hosted Docker registry
+
 Say you host some Docker images yourself, and use a password to access your self-hosted Docker images.
 In addition to self-hosting, you also pull images from Docker Hub, without a password.
 In this example you would configure a specific Docker host like this:
@@ -199,4 +206,21 @@ module.exports = {
 };
 ```
 
+#### ChartMuseum
+
+Maybe you're running your own ChartMuseum server to host your private Helm Charts.
+This is how you connect to a private Helm repository:
+
+```js
+module.exports = {
+  hostRules: [
+    {
+      hostName: 'your.host.io',
+      username: '<your-username>',
+      password: 'process.env.SELF_HOSTED_HELM_CHARTS_PASSWORD',
+    },
+  ],
+};
+```
+
 If you need to configure per-repository credentials then you can also configure the above within a repository's Renovate config (e.g. `renovate.json`).

docs/usage/rust.md

@@ -0,0 +1,29 @@
+---
+title: Rust crates
+description: Rust crates support in Renovate
+---
+
+# Automated Dependency Updates for Rust crates
+
+Renovate supports upgrading dependencies in `Cargo.toml` files and their accompanying `Cargo.lock` checksums.
+
+## How it works
+
+1. Renovate searches in each repository for any `Cargo.toml` files
+1. Renovate extracts existing dependencies from `[dependencies]`, `[dev-dependencies]` and `[build-dependencies]`
+1. Renovate attempts to find and parse a `.cargo/config.toml` file to discover index URLs for private registries
+1. Renovate resolves the dependency's version using the crates.io API or by cloning the index URL
+1. If Renovate finds an update, Renovate will use `cargo update` to update both `Cargo.toml` and `Cargo.lock`
+
+## Enabling Rust Modules Updating
+
+Renovate updates Rust crates by default.
+
+## Private crate registries and private git dependencies
+
+If any dependencies are hosted in private git repositories, [Git Authentication for cargo](https://doc.rust-lang.org/cargo/appendix/git-authentication.html) must be set up.
+
+If any dependencies are hosted on private crate registries (ie., not on `crates.io`), then credentials should be set up in such a way that the Git command-line is able to clone the registry index.
+Third-party crate registries usually provide instructions to achieve this.
+
+Both of these are currently only possible when running Renovate self-hosted.

docs/usage/self-hosted-configuration.md

@@ -92,6 +92,10 @@ If you configure this to be different to the `baseDir`, it means you can have on
 
 Set to `false` to prevent usage of `--ignore-platform-reqs` in the Composer package manager.
 
+## customEnvVariables
+
+This configuration will be applied after all other environment variables so that it can be used to override defaults.
+
 ## dockerImagePrefix
 
 Override the default renovate sidecar Docker containers image prefix from `docker.io/renovate` to a custom value, so renovate will pull images from a custom Docker registry.
@@ -168,6 +172,8 @@ By configuring using the environment it means that debug logging starts from the
 
 Additionally, if you configure `LOG_FORMAT=json` in env then logging will be done in JSON format instead of "pretty" format, which is usually better if you're doing any ingestion or parsing of the logs.
 
+Warning: Configuring `logLevel` config option or `--log-level` cli option is deprecated and will be removed in a major version.
+
 ## onboarding
 
 Set this to `false` if (a) you configure Renovate entirely on the bot side (i.e. empty `renovate.json` in repositories) and (b) you wish to run Renovate on every repository the bot has access to, and (c) you wish to skip the onboarding PRs.