Skip to content

Commit

Permalink
Merge branch 'master' into add-bumpversion-support-to-helm-values
Browse files Browse the repository at this point in the history
  • Loading branch information
chgl authored Jan 21, 2021
2 parents d7eb631 + d0531f5 commit b1cb020
Show file tree
Hide file tree
Showing 108 changed files with 2,357 additions and 563 deletions.
6 changes: 2 additions & 4 deletions data/extract.py
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down
3 changes: 2 additions & 1 deletion docs/development/configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 },
};
Expand All @@ -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.
Expand Down
19 changes: 19 additions & 0 deletions docs/development/issue-labeling.md
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand Down Expand Up @@ -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>

Expand All @@ -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>
Expand Down
93 changes: 93 additions & 0 deletions docs/development/triage-guide.md
Original file line number Diff line number Diff line change
@@ -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".
8 changes: 5 additions & 3 deletions docs/usage/configuration-options.md
Original file line number Diff line number Diff line change
Expand Up @@ -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"
}
}
```
Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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.

Expand Down
24 changes: 24 additions & 0 deletions docs/usage/docker.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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:
Expand All @@ -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`).
29 changes: 29 additions & 0 deletions docs/usage/rust.md
Original file line number Diff line number Diff line change
@@ -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.
6 changes: 6 additions & 0 deletions docs/usage/self-hosted-configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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.
Expand Down
Loading

0 comments on commit b1cb020

Please sign in to comment.