diff --git a/website/docs/_posts/2017-07-13-configure-renovate.md b/website/docs/_posts/2017-07-13-configure-renovate.md
index 18648d730219d657c55bada3578a1a857d5f7731..46527586b929c3eb4bbc9b62e4b7ce5ab4835a2e 100644
--- a/website/docs/_posts/2017-07-13-configure-renovate.md
+++ b/website/docs/_posts/2017-07-13-configure-renovate.md
@@ -14,7 +14,7 @@ Once you have enabled Renovate on a repository, you will receive a "Configure Re
## No Risk Onboarding
-Conveniently, Renovate will not make any changes to your repository or raise any further Pull Requests until after you *close or merge* this initial Pull Request. So if there is anything about the Pull Request that you don't like or understand, take your time to read [documentation](/docs) or ask questions in one of our support forums and merge the PR only once you're satisfied with the result. You can edit your Renovate configuration **within this `renovate/configure` branch** and Renovate will keep updating the description in the PR to match, so you can keep doing that until you're satisfied with the results.
+Conveniently, Renovate will not make any changes to your repository or raise any further Pull Requests until after you _close or merge_ this initial Pull Request. So if there is anything about the Pull Request that you don't like or understand, take your time to read [documentation](/docs) or ask questions in one of our support forums and merge the PR only once you're satisfied with the result. You can edit your Renovate configuration **within this `renovate/configure` branch** and Renovate will keep updating the description in the PR to match, so you can keep doing that until you're satisfied with the results.
## Check for Warnings
@@ -22,9 +22,9 @@ If you have any Warnings or Errors listed, see if you need or want to make any c
## Configuration Location
-The Configure Renovate PR will include a `renovate.json` file in the root directory, with suggested default settings.
+The Configure Renovate PR will include a `renovate.json` file in the root directory, with suggested default settings.
-It's not mandatory to have a `renovate.json` in your repository but strongly recommended. If Renovate's default settings work well for you then you can simply close this PR unmerged to run Renovate without *any* override configuration. However it's recommended that you try deleting the `renovate.json` from the `renovate/configure` branch first to check that the results are as you wish.
+It's not mandatory to have a `renovate.json` in your repository but strongly recommended. If Renovate's default settings work well for you then you can simply close this PR unmerged to run Renovate without _any_ override configuration. However it's recommended that you try deleting the `renovate.json` from the `renovate/configure` branch first to check that the results are as you wish.
If you want to override some of Renovate's default settings but not have a `renovate.json`, then you can instead add the same settings to a `"renovate"` section in your `package.json`. Note though that if you run a monorepo with more than one `package.json` file then you may need to add the same configuration to all of them. Again, please make these changes within the `renovate/configure` branch of this PR to make sure that the results match your expectations.
@@ -34,16 +34,16 @@ Alternatively, if you prefer to use "dot files" then you can add the same JSON c
Most of the settings in the `renovate.json` onboarding configuration are defaults, however usually this configuration file will have some default overrides in it, such as:
-- Automatically enabling angular-style semantic commits if your repository uses them
-- Setting `pinVersions` to false for `dependencies` unless your `package.json` file are all `private`
+* Automatically enabling angular-style semantic commits if your repository uses them
+* Setting `pinVersions` to false for `dependencies` unless your `package.json` file are all `private`
## Common Overrides
Please check the docs on this website for an exhaustive Configuration Reference, however here are some of the most commonly changed (overridden) configuration settings:
-- **pinVersions**: By default it's `true` (all ranges will be converted to pinned versions) but many people prefer to keep ranges
-- **labels**: Labels to assign to Pull Requests
-- **assignees**: GitHub users to assign the Pull Requests to
+* **pinVersions**: By default it's `true` (all ranges will be converted to pinned versions) but many people prefer to keep ranges
+* **labels**: Labels to assign to Pull Requests
+* **assignees**: GitHub users to assign the Pull Requests to
Renovate will update your PR description each time it finds changes.
diff --git a/website/docs/_posts/2017-07-24-data-security.md b/website/docs/_posts/2017-07-24-data-security.md
index c79403d8eb334e74e8ac34a202088e7a92e622ec..a793db46fdc4bce1b8c39719847ac0601c3e94fd 100644
--- a/website/docs/_posts/2017-07-24-data-security.md
+++ b/website/docs/_posts/2017-07-24-data-security.md
@@ -18,12 +18,12 @@ If you have any suggestions or questions about our security, please contact us a
The most important consideration for GitHub App security is the [Private Key](https://developer.github.com/apps/building-integrations/setting-up-and-registering-github-apps/registering-github-apps/#generating-a-private-key) used to access installations. This key is metaphorically the "key to the kingdom" and is essentially the only thing anybody needs to gain access to all repositories on which the Renovate App has been installed, so we have handled it with great caution:
-- The key is not saved to disk *anywhere*. We do not keep a backup of it on any device, thumbdrive, or password manager.
-- The key is saved in one location - as an [AWS EC2 Parameter Store](http://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) "Secure String"
-- The EC2 instance we run Renovate on gains access to this Secure String using its IAM Role permissions
-- The private key is not exposed/saved to "env" at any time
-- There exists no generated AWS "Access Key" that has permissions to either (a) read from EC2 Parameter Store, or (b) create IAM users or roles with permissions to access the secure string, or (c) create a new EC2 instance that could gain access
-- When the Renovate App runs and decrypts the Private Key, it is stored in memory only as long as necessary to retrieve temporary tokens for each installation, and it is never written to any log
+* The key is not saved to disk _anywhere_. We do not keep a backup of it on any device, thumbdrive, or password manager.
+* The key is saved in one location - as an [AWS EC2 Parameter Store](http://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html) "Secure String"
+* The EC2 instance we run Renovate on gains access to this Secure String using its IAM Role permissions
+* The private key is not exposed/saved to "env" at any time
+* There exists no generated AWS "Access Key" that has permissions to either (a) read from EC2 Parameter Store, or (b) create IAM users or roles with permissions to access the secure string, or (c) create a new EC2 instance that could gain access
+* When the Renovate App runs and decrypts the Private Key, it is stored in memory only as long as necessary to retrieve temporary tokens for each installation, and it is never written to any log
## App Ownership
@@ -33,10 +33,10 @@ We have chosen to assign ownership of the apps to the GitHub organization "`reno
The Renovate App requires the following GitHub Permissions:
-- **Read** access to administration and metadata
-- **Write** access to commit statuses
-- **Write** access to issues and pull requests
-- **Write** access to repository content
+* **Read** access to administration and metadata
+* **Write** access to commit statuses
+* **Write** access to issues and pull requests
+* **Write** access to repository content
The "Forking Renovate" App requires only read-only access to repository content because it submits PRs from its own fork of each repository.
@@ -46,8 +46,8 @@ We will explain the need for each of these here:
This is necessary so that Renovate can learn enough about the repository to detect settings without manual configuration. As an example, this permission is used so Renovate can detect:
-- The merge types allowed in the repository (e.g. merge commit, merge squash, rebase)
-- Whether the repository status checks require Pull Requests to be up-to-date with base branch before merging
+* The merge types allowed in the repository (e.g. merge commit, merge squash, rebase)
+* Whether the repository status checks require Pull Requests to be up-to-date with base branch before merging
##### **Write** access to commit statuses
@@ -55,7 +55,7 @@ Renovate can utilise commit statuses for purposes such as to warn if a package i
##### **Write** access to issues
-Renovate makes use of repository issues if it needs to alert of configuration errors. For example, if someone updates the `renovate.json` configuration with invalid JSON that cannot be parsed, Renovate will stop processing the repository and instead raise an "Action Required" issue to alert users to fix it.
+Renovate makes use of repository issues if it needs to alert of configuration errors. For example, if someone updates the `renovate.json` configuration with invalid JSON that cannot be parsed, Renovate will stop processing the repository and instead raise an "Action Required" issue to alert users to fix it.
##### **Write** access to Pull Requests
@@ -63,7 +63,7 @@ This permission is used heavily today, for instance every time Renovate finds an
##### Write access to repository contents (i.e. code)
-Renovate needs write access to code in order to create branches within the repository, or to automerge any updates itself. Although this necessary permission gives us access to *all files in a repository*, we will only write changes to package definitions files (like `package.json` or `Dockerfile`), or lock files like `package-lock.json` and `yarn.lock`. These files may be located in any subdirectory too (e.g. for monorepo configurations).
+Renovate needs write access to code in order to create branches within the repository, or to automerge any updates itself. Although this necessary permission gives us access to _all files in a repository_, we will only write changes to package definitions files (like `package.json` or `Dockerfile`), or lock files like `package-lock.json` and `yarn.lock`. These files may be located in any subdirectory too (e.g. for monorepo configurations).
[Forking Renovate](https://github.com/apps/forking-renovate) does not require write access to repository contents, because it submits PRs from branches within its own forks of repositories.
@@ -85,8 +85,8 @@ Renovate will always be run from the "production" server and the app's credentia
All logs are stored in the AWS Oregon region as described above. We currently log to:
-- CloudWatch Logs (30 day retention)
-- S3 (30 day retention)
+* CloudWatch Logs (30 day retention)
+* S3 (30 day retention)
Select metadata (such as each run's result/status) is extracted from logs and saved to an RDS Postgres instance with no expiry.
diff --git a/website/docs/_posts/2017-07-26-dependency-pinning.md b/website/docs/_posts/2017-07-26-dependency-pinning.md
index 72b86a8741cbac887a605471b92743a2f08b9aa0..c447d5a4d757e77b81f5ac786da18b26f1807443 100644
--- a/website/docs/_posts/2017-07-26-dependency-pinning.md
+++ b/website/docs/_posts/2017-07-26-dependency-pinning.md
@@ -26,7 +26,7 @@ For projects of any type, the main reason to use ranges is so that you can "auto
#### Tilde vs Caret
-If you're familiar with the theory of semver, you might think that you only need to use tilde ranges (e.g. `"~1.1.0"`) to get bug fixes, rather than caret ranges (e.g. `"^1.1.0"`). This is true in theory but not in practice. The reality is that for most projects, fixes are not "backported" to previous minor releases, and minor releases themselves may include fixes. So for example release `1.2.0` may include one new feature and one fix, so if you stick with `1.1.0` then you will miss out on the fix as there will never be a `1.1.1` once `1.2.0` is already released. This is the *reality* of most open source packages.
+If you're familiar with the theory of semver, you might think that you only need to use tilde ranges (e.g. `"~1.1.0"`) to get bug fixes, rather than caret ranges (e.g. `"^1.1.0"`). This is true in theory but not in practice. The reality is that for most projects, fixes are not "backported" to previous minor releases, and minor releases themselves may include fixes. So for example release `1.2.0` may include one new feature and one fix, so if you stick with `1.1.0` then you will miss out on the fix as there will never be a `1.1.1` once `1.2.0` is already released. This is the _reality_ of most open source packages.
#### Ranges for Libraries
@@ -44,11 +44,11 @@ Let's say that a "faulty" version `1.2.0` of `foobar` is released and it breaks
If you were using default caret semver ranges, then your `master` branch is now "broken" because its `package.json` says that any version 1.x above 1.1.0 is acceptable, and npm will choose the latest (`1.2.0`). You would need to manually check and work out which dependency caused the failure (`foobar` may not have been the only dependency to have "automatically" upgraded) and then you would need to pin the dependency yourself to stop `npm` installing `1.2.0`.
-Consider if instead you were *pinning* dependency versions and the same thing happened. Your `master` would not be broken because it's pinned to `foobar@1.1.0` - instead you'd just have a Pull Request for upgrading to `foobar@1.2.0` which would fail. You'd know not to merge it and can wait for `foobar@1.2.1` or later when it's fixed.
+Consider if instead you were _pinning_ dependency versions and the same thing happened. Your `master` would not be broken because it's pinned to `foobar@1.1.0` - instead you'd just have a Pull Request for upgrading to `foobar@1.2.0` which would fail. You'd know not to merge it and can wait for `foobar@1.2.1` or later when it's fixed.
-Now consider a similar theoretical scenario where `foobar@1.2.0` is faulty but it is *not* caught by any of your automated tests. This is more common and more dangerous.
+Now consider a similar theoretical scenario where `foobar@1.2.0` is faulty but it is _not_ caught by any of your automated tests. This is more common and more dangerous.
-If you were using semver ranges then this new version of `foobar` will likely be deployed to production before you notice errors and need to roll back. Like before, you need to manually work out which dependency caused it and pin it manually by editing `package.json` one dependency at a time.
+If you were using semver ranges then this new version of `foobar` will likely be deployed to production before you notice errors and need to roll back. Like before, you need to manually work out which dependency caused it and pin it manually by editing `package.json` one dependency at a time.
If you were instead pinning `foobar` then you would receive a PR for `foobar@1.2.0` which awaits your approval. So first of all, you can choose to read the release notes and/or visually inspect the branch yourself before merging, hopefully saving you from pushing this faulty code to production.
@@ -68,7 +68,7 @@ The increased volume of Pull Requests for upgrading dependencies may be consider
There are some dependencies that either (a) don't have the potential to break something in production, or (b) are fully tested by your tests.
-For example, it's essentially impossible for `eslint` to break anything in production. If your build/tests pass, then you are fine. Therefore you should consider enabling automerge for all lint packages so save yourself the pointless click. In this case you maybe wake up to 5/10 of your overnight Pull Requests already merged by themself.
+For example, it's essentially impossible for `eslint` to break anything in production. If your build/tests pass, then you are fine. Therefore you should consider enabling automerge for all lint packages to save yourself the pointless click. In this case you maybe wake up to 5/10 of your overnight Pull Requests already merged by themself.
Another example of a good candidate for automerging might be a database driver like `node-postgres` (`pg` on npm), if you have 100% test coverage of your API. In that case if the `pg` package has a minor or patch update and passes all tests then you may as well merge it automatically if you were not going to do a manual inspection anyway.
@@ -76,21 +76,21 @@ Another example of a good candidate for automerging might be a database driver l
In the above suggestion of Pull Request automerging, you might still find it annoying if you receive GitHub Notifications for every PR that is created and merged. In that case, you could set `automergeType` to `branch-push`, which means Renovate will:
-- Create a new branch for testing
-- Wait until after tests have completed
-- Push the commit directly to `master` if tests pass, or
-- Raise a PR only if tests failed
+* Create a new branch for testing
+* Wait until after tests have completed
+* Push the commit directly to `master` if tests pass, or
+* Raise a PR only if tests failed
With this approach, updates will be essentially "silent" - causing no notifications - but you will be able to see each commit on `master` of course.
##### Scheduling
-Although it can feel satisfying to receive updates "immediately" when they're available, the reality is that you usually don't *need* updates so frequently. And worse still, npm package versions that are less than 24 hours [can be unpublished](http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy), which would really break your build if you've pinned to a version that no longer exists.
+Although it can feel satisfying to receive updates "immediately" when they're available, the reality is that you usually don't _need_ updates so frequently. And worse still, npm package versions that are less than 24 hours [can be unpublished](http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy), which would really break your build if you've pinned to a version that no longer exists.
So to reduce the interruptions of automated dependency updates, consider putting Renovate on a schedule, such as:
-- Update only on weekends? This way you update packages at most once per week, *and* your CI build runners are likely to be idle anyway.
-- Update daily, but between hours like midnight and 5am? That way notifications don't pop up in people's feed while they're working, *and* you also get the benefit of not tying up build machines when developers need to use them.
+* Update only on weekends? This way you update packages at most once per week, _and_ your CI build runners are likely to be idle anyway.
+* Update daily, but between hours like midnight and 5am? That way notifications don't pop up in people's feed while they're working, _and_ you also get the benefit of not tying up build machines when developers need to use them.
##### Grouping related packages
@@ -102,11 +102,11 @@ Since both `yarn` and `npm@5` now support lock files, it's a common question to
-Lock files are a great companion to semver ranges *or* pinning dependencies, because these files lock (pin) deeper into your dependency tree than you see in `package.json`.
+Lock files are a great companion to semver ranges _or_ pinning dependencies, because these files lock (pin) deeper into your dependency tree than you see in `package.json`.
#### What a lock file will do for you
-A lock file will lock down the exact dependencies and *sub*-dependencies that your project uses, so that everyone running `npm install` or `yarn install` will install the exact same dependencies as the person or bot that last updated the lock file.
+A lock file will lock down the exact dependencies and _sub_-dependencies that your project uses, so that everyone running `npm install` or `yarn install` will install the exact same dependencies as the person or bot that last updated the lock file.
To reuse an earlier example, this means that you could have `foobar@^1.1.0` in your `package.json` and be locked to `1.1.0` in your lock file, so that when the broken `foobar@1.2.0` is released, nobody on the team installs it.
@@ -126,9 +126,9 @@ Essentially, the lock file does not solve the same semver problems that pinning
We recommend:
-1. Any apps (web or node.js) that aren't `require()`'d by other packages should pin all types of dependencies for greatest reliability/predictability.
-2. Browser or dual browser/node.js libraries that are consumed/`required()`'d by others should keep using semver ranges for `dependencies` but can use pinned dependencies for `devDependencies`.
-3. Node.js-only libraries can consider pinning all dependencies, because application size/duplicate dependencies are not as much a concern in node.js compared to the browser.
-4. Use a lock file if you can.
+1. Any apps (web or node.js) that aren't `require()`'d by other packages should pin all types of dependencies for greatest reliability/predictability.
+2. Browser or dual browser/node.js libraries that are consumed/`required()`'d by others should keep using semver ranges for `dependencies` but can use pinned dependencies for `devDependencies`.
+3. Node.js-only libraries can consider pinning all dependencies, because application size/duplicate dependencies are not as much a concern in node.js compared to the browser.
+4. Use a lock file if you can.
As noted earlier, when you pin dependencies then you will see an increase in the raw volume of dependency updates, compared to if you use ranges. If/when this starts bothering you, add Renovate rules to reduce the volume, such as scheduling updates, grouping them, or automerging "safe" ones.
diff --git a/website/docs/_posts/2017-07-31-private-modules.md b/website/docs/_posts/2017-07-31-private-modules.md
index eb0db8df703cf530ba71d9218872bd3c2a9ad96e..6702da8062720a33914cbfafdfe95dbe5d93a7c0 100644
--- a/website/docs/_posts/2017-07-31-private-modules.md
+++ b/website/docs/_posts/2017-07-31-private-modules.md
@@ -20,9 +20,9 @@ Assuming the lookup succeeds (solutions for that are described later in this doc
#### 2. Lock file generation
-If you are using a lock file (yarn's `yarn.lock` or npm's `package-lock.json`) then Renovate needs to regenerate that lock file whenever *any* npm module listed in your `package.json` is updated to a new version.
+If you are using a lock file (yarn's `yarn.lock` or npm's `package-lock.json`) then Renovate needs to regenerate that lock file whenever _any_ npm module listed in your `package.json` is updated to a new version.
-To do this, Renovate will run `npm install` or `yarn install` and save the resulting lock file. The "problem" here is that for the install to succeed - and lock file to be generated - then all modules must be found, including private ones. Therefore if a private module can't be found, and you're using lock files, then the private module install failure will then block *any* module from being renovated.
+To do this, Renovate will run `npm install` or `yarn install` and save the resulting lock file. The "problem" here is that for the install to succeed - and lock file to be generated - then all modules must be found, including private ones. Therefore if a private module can't be found, and you're using lock files, then the private module install failure will then block _any_ module from being renovated.
Because lock files are quickly becoming "the new standard", we think it's essential that Renovate can access/install any private modules necessary.
@@ -30,7 +30,7 @@ Because lock files are quickly becoming "the new standard", we think it's essent
#### Authenticate the "renovate" npm user to your private npm module
-The Renovate app itself runs with credentials for the "renovate" user on npm. Therefore, a simple solution to enabling private modules is to treat Renovate as another account on your team and add the npm user "renovate" to the necessary projects that Renovate needs to access. Renovate will then use its own npm authentication if it finds none in your repository.
+The Renovate app itself runs with credentials for the "renovate" user on npm. Therefore, a simple solution to enabling private modules is to treat Renovate as another account on your team and add the npm user "renovate" to the necessary projects that Renovate needs to access. Renovate will then use its own npm authentication if it finds none in your repository.
#### Commit .npmrc file into repository
@@ -44,7 +44,8 @@ The above solution maybe have a downside that all users of the repository (e.g.
```json
{
- "npmrc": "//some.registry.com/:_authToken=abcdefghi-1234-jklmno-aac6-12345567889"
+ "npmrc":
+ "//some.registry.com/:_authToken=abcdefghi-1234-jklmno-aac6-12345567889"
}
```
@@ -66,7 +67,7 @@ It's recommended that you use the [npm token](https://docs.npmjs.com/cli/token)
#### Add encrypted .npmrc file into repository
-Even if your repository is private itself, you may still prefer not to put an unencrypted `.npmrc` file into your renovate config. An alternative is to put an *encrypted* version into the config, inside an `encrypted` configuration block.
+Even if your repository is private itself, you may still prefer not to put an unencrypted `.npmrc` file into your renovate config. An alternative is to put an _encrypted_ version into the config, inside an `encrypted` configuration block.
If you are using the hosted Renovate app service on GitHub, you can do this using the [renovate-encrypt](https://npmjs.com/package/renovate-encrypt) module. To get an encrypted value, use it like this:
@@ -74,6 +75,7 @@ If you are using the hosted Renovate app service on GitHub, you can do this usin
$ renovate-encrypt < .npmrc
WOTWu+jliBtXYz3CU2eI7dDyMIvSJKS2N5PEHZmLB3XKT3vLaaYTGCU6m92Q9FgdaM/q2wLYun2JrTP4GPaW8eGZ3iiG1cm7lgOR5xPnkCzz0DUmSf6Cc/6geeVeSFdJ0zqlEAhdNMyJ4pUW6iQxC3WJKgM/ADvFtme077Acvc0fhCXv0XvbNSbtUwHF/gD6OJ0r2qlIzUMGJk/eI254xo5SwWVctc1iZS9LW+L0/CKjqhWh4SbyglP3lKE5shg3q7mzWDZepa/nJmAnNmXdoVO2aPPeQCG3BKqCtCfvLUUU/0LvnJ2SbQ1obyzL7vhh2OF/VsATS5cxbHvoX/hxWQ==
```
+
(if installed globally)
or just run it without installing using `npx`:
@@ -87,8 +89,9 @@ You will then get an encrypted string that you can substitute into your renovate
```json
{
- "encrypted" : {
- "npmrc": "WOTWu+jliBtXYz3CU2eI7dDyMIvSJKS2N5PEHZmLB3XKT3vLaaYTGCU6m92Q9FgdaM/q2wLYun2JrTP4GPaW8eGZ3iiG1cm7lgOR5xPnkCzz0DUmSf6Cc/6geeVeSFdJ0zqlEAhdNMyJ4pUW6iQxC3WJKgM/ADvFtme077Acvc0fhCXv0XvbNSbtUwHF/gD6OJ0r2qlIzUMGJk/eI254xo5SwWVctc1iZS9LW+L0/CKjqhWh4SbyglP3lKE5shg3q7mzWDZepa/nJmAnNmXdoVO2aPPeQCG3BKqCtCfvLUUU/0LvnJ2SbQ1obyzL7vhh2OF/VsATS5cxbHvoX/hxWQ=="
+ "encrypted": {
+ "npmrc":
+ "WOTWu+jliBtXYz3CU2eI7dDyMIvSJKS2N5PEHZmLB3XKT3vLaaYTGCU6m92Q9FgdaM/q2wLYun2JrTP4GPaW8eGZ3iiG1cm7lgOR5xPnkCzz0DUmSf6Cc/6geeVeSFdJ0zqlEAhdNMyJ4pUW6iQxC3WJKgM/ADvFtme077Acvc0fhCXv0XvbNSbtUwHF/gD6OJ0r2qlIzUMGJk/eI254xo5SwWVctc1iZS9LW+L0/CKjqhWh4SbyglP3lKE5shg3q7mzWDZepa/nJmAnNmXdoVO2aPPeQCG3BKqCtCfvLUUU/0LvnJ2SbQ1obyzL7vhh2OF/VsATS5cxbHvoX/hxWQ=="
}
}
```
@@ -107,7 +110,8 @@ The configure it like:
```json
{
"encrypted": {
- "npmToken": "xxT19RIdhAh09lkhdrK39HzKNBn3etoLZAwHdeJ25cX+5y52a9kAC7flXmdw5JrkciN08aQuRNqDaKxp53IVptB5AYOnQPrt8MCT+x0zHgp4A1zv1QOV84I6uugdWpFSjPUkmLGMgULudEZJMlY/dAn/IVwf/IImqwazY8eHyJAA4vyUqKkL9SXzHjvS+OBonQ/9/AHYYKmDJwT8vLSRCKrXxJCdUfH7ZnikZbFqjnURJ9nGUHP44rlYJ7PFl05RZ+X5WuZG/A27S5LuBvguyQGcw8A2AZilHSDta9S/4eG6kb22jX87jXTrT6orUkxh2WHI/xvNUEout0gxwWMDkA=="
+ "npmToken":
+ "xxT19RIdhAh09lkhdrK39HzKNBn3etoLZAwHdeJ25cX+5y52a9kAC7flXmdw5JrkciN08aQuRNqDaKxp53IVptB5AYOnQPrt8MCT+x0zHgp4A1zv1QOV84I6uugdWpFSjPUkmLGMgULudEZJMlY/dAn/IVwf/IImqwazY8eHyJAA4vyUqKkL9SXzHjvS+OBonQ/9/AHYYKmDJwT8vLSRCKrXxJCdUfH7ZnikZbFqjnURJ9nGUHP44rlYJ7PFl05RZ+X5WuZG/A27S5LuBvguyQGcw8A2AZilHSDta9S/4eG6kb22jX87jXTrT6orUkxh2WHI/xvNUEout0gxwWMDkA=="
}
}
```
diff --git a/website/docs/_posts/2017-08-18-config-presets.md b/website/docs/_posts/2017-08-18-config-presets.md
index 10902beeb8cb398408c44c3f10bd6db40674f4c1..d1c8b30caa437aae1da5b2a56c00220418b53c2c 100644
--- a/website/docs/_posts/2017-08-18-config-presets.md
+++ b/website/docs/_posts/2017-08-18-config-presets.md
@@ -81,6 +81,7 @@ Then in each of your repositories you can add your renovate config like:
Any repository including this config will then adopt the rules of the default `library` preset but schedule it on weeknights or weekends.
Note: if you prefer to publish using the namespace `@fastcore/renovate-config` then you would use the `@` prefix instead:
+
```json
"extends": ["@fastcore"]
```
diff --git a/website/docs/_posts/2017-10-05-configuration-options.md b/website/docs/_posts/2017-10-05-configuration-options.md
index 24723e476132ab4ea0bf4698e8d66f0c2f35c735..bd5400655feeb57c5ea9def10ceb804abd35516a 100644
--- a/website/docs/_posts/2017-10-05-configuration-options.md
+++ b/website/docs/_posts/2017-10-05-configuration-options.md
@@ -7,6 +7,7 @@ description: Configuration Options usable in renovate.json or package.json
type: Document
order: 0
---
+
This document describes all the configuration options you may configure in a `renovate.json` file or within a `"renovate"` section of your `package.json`. Note that any config in a `package.json` will apply only to that package file, so this is also one way you can specify different behaviour for different `package.json files`. Similarly, if you have a monorepo and want your config to apply to all package files then you need to define it in a `renovate.json`;
Also, be sure to check out Renovate's [shareabe config presets](/docs/configuration-reference/config-presets) to save yourself from reinventing any wheels.
@@ -17,10 +18,10 @@ If you have any questions about the below config options, or would like to get h
Assignees for Pull Requests
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | [] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | [] |
Must be valid usernames.
@@ -28,14 +29,14 @@ Must be valid usernames.
Configure if Renovate should merge passing PRs itself..
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | false |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | false |
By default, Renovate raises PRs but leaves them to someone/something else to merge them. By configuring this setting, you can enable Renovate to automerge branches or PRs itself, therefore reducing the amount of human intervention required.
-Usually you won't want to automerge *all* PRs, for example most people would want to leave major dependency updates to a human to review first. In that case you will want to embed this setting inside `major`, `minor`, or `patch` configuration options. For example, you could add this to your `renovate.json` to automerge only non-major updates:
+Usually you won't want to automerge _all_ PRs, for example most people would want to leave major dependency updates to a human to review first. In that case you will want to embed this setting inside `major`, `minor`, or `patch` configuration options. For example, you could add this to your `renovate.json` to automerge only non-major updates:
```json
"automerge": true,
@@ -58,13 +59,13 @@ Warning: GitHub currently has a bug where automerge won't work if a GitHub Organ
Type of automerge approach to use.
-| name | value |
-|----------|-----------------------------|
-| type | string |
+| name | value |
+| ------------ | -------------------------------------------- |
+| type | string |
| valid values | "branch-merge-commit", "branch-push" or "pr" |
-| default | "pr" |
+| default | "pr" |
-Renovate will default to automerging after creating PRs, but you can override that to automerge *without* PRs. There are two ways to merge branch upgrades: merge commits, and branch push.
+Renovate will default to automerging after creating PRs, but you can override that to automerge _without_ PRs. There are two ways to merge branch upgrades: merge commits, and branch push.
Merge commits will employ the standard GitHub "merge commit" API, just like when you merge a PR with merge commit setting. The downside of this aproach is that you will end up with merge commits and not a nice clean default branch!
@@ -74,11 +75,10 @@ Branch push employs GitHub's low-level `git` API to push the Renovate upgrade di
A custom base branch to target for pull requests.
-| name | value |
-|----------|-----------------------------|
-| type | string |
-| default | `''` |
-
+| name | value |
+| ------- | ------ |
+| type | string |
+| default | `''` |
If left default (empty) then the default branch of the repository is used.
@@ -90,10 +90,10 @@ You also may add this setting into the `renovate.json` file as part of the "Conf
Prefix to be used for all branch names
-| name | value |
-|----------|-----------------------------|
-| type | string |
-| default | renovate/ |
+| name | value |
+| ------- | --------- |
+| type | string |
+| default | renovate/ |
You can modify this field if you want to change the prefix used. For example if you want branches to be like `deps/eslint-4.x` instead of `renovate/eslint-4.x` then you set `branchPrefix` = `deps/`. Or if you wish to avoid forward slashes in branch names then you could use `renovate_` instead, for example.
@@ -101,10 +101,10 @@ You can modify this field if you want to change the prefix used. For example if
Branch name template
-| name | value |
-|----------|-----------------------------|
-| type | handlebars template |
-| default | {% raw %}{{renovatePrefix}}{{depName}}-{{newVersionMajor}}.x{% endraw %} |
+| name | value |
+| ------- | ------------------------------------------------------------------------ |
+| type | handlebars template |
+| default | {% raw %}{{renovatePrefix}}{{depName}}-{{newVersionMajor}}.x{% endraw %} |
It's recommended to use our default templates, but you may override branch name if you really wish. It's recommended to still keep `depName` and `newVersionMajor` in the branch name to make sure all other Renovate features can still work.
@@ -114,10 +114,10 @@ Example branch name: `renovate/eslint-4.x`.
Commit message template
-| name | value |
-|----------|-----------------------------|
-| type | handlebars template |
-| default | {% raw %}{{semanticPrefix}}Update dependency {{depName}} to version {{newVersion}}{% endraw %} |
+| name | value |
+| ------- | ---------------------------------------------------------------------------------------------- |
+| type | handlebars template |
+| default | {% raw %}{{semanticPrefix}}Update dependency {{depName}} to version {{newVersion}}{% endraw %} |
The commit message is less important than branchName so you may override it if you wish.
@@ -127,10 +127,10 @@ Example commit message: "chore(deps): Update dependency eslint to version 4.0.1"
Configuration specific for `package.json > dependencies`.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | {"semanticPrefix": "fix(deps):"} |
+| name | value |
+| ------- | -------------------------------- |
+| type | object |
+| default | {"semanticPrefix": "fix(deps):"} |
Extend this if you wish to configure rules specificly for `dependencies` and not `devDependencies` or `optionalDependencies`.
@@ -138,10 +138,10 @@ Extend this if you wish to configure rules specificly for `dependencies` and not
Configuration specific for `package.json > devDependencies`.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | {} |
+| name | value |
+| ------- | ------ |
+| type | object |
+| default | {} |
Extend this if you wish to configure rules specificly for `devDependencies` and not `dependencies` or `optionalDependencies`.
@@ -149,10 +149,10 @@ Extend this if you wish to configure rules specificly for `devDependencies` and
Configuration specific for Dockerfile updates.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | { enabled: false } |
+| name | value |
+| ------- | ------------------ |
+| type | object |
+| default | { enabled: false } |
Set enabled to `true` to enable Dockerfile FROM updating.
@@ -160,10 +160,10 @@ Set enabled to `true` to enable Dockerfile FROM updating.
Enable or disable Renovate.
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | true |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | true |
Renovate is enabled for all packages by default, but this setting allows you to disable Renovate for specific packages, dependency types, package files, or even for the whole repository.
@@ -190,10 +190,10 @@ To disable Renovate for `dependencies` but keep it for `devDependencies` you cou
A list of package names inside a package rule which are to be excluded/ignored.
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | [] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | [] |
Use this field if you want to have one or more exact name matches excluded in your package rule. See also `packageNames`.
@@ -201,10 +201,10 @@ Use this field if you want to have one or more exact name matches excluded in yo
A list of regex package patterns inside a package rule which are to be excluded/ignored.
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | [] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | [] |
Use this field if you want to have one or more package name patterns excluded in your package rule. See also `packagePatterns`.
@@ -212,10 +212,10 @@ Use this field if you want to have one or more package name patterns excluded in
Preset configs to use/extend.
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | [] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | [] |
See https://renovateapp.com/docs/configuration-reference/config-presets for details.
@@ -223,10 +223,10 @@ See https://renovateapp.com/docs/configuration-reference/config-presets for deta
A configuration object containing strings encrypted with Renovate's public key.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | {} |
+| name | value |
+| ------- | ------ |
+| type | object |
+| default | {} |
See http://localhost:4000/docs/deep-dives/private-modules for details on how this is used to encrypte npm tokens.
@@ -234,21 +234,21 @@ See http://localhost:4000/docs/deep-dives/private-modules for details on how thi
Group configuration to apply if groupName is provided.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | {<br /> "recreateClosed": true,<br /> "branchName": "template",<br /> "commitMessage": "template",<br /> "prTitle": "template",<br /> "prBody": "template"<br />} |
+| name | value |
+| ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| type | object |
+| default | {<br /> "recreateClosed": true,<br /> "branchName": "template",<br /> "commitMessage": "template",<br /> "prTitle": "template",<br /> "prBody": "template"<br />} |
-The default configuration for groups are essentially internal to Renovate and you normally shouldn't need to modify them. However, you may choose to *add* settings to any group by defining your own `group` configuration object.
+The default configuration for groups are essentially internal to Renovate and you normally shouldn't need to modify them. However, you may choose to _add_ settings to any group by defining your own `group` configuration object.
## groupName
Human understandable name for a dependency group
-| name | value |
-|----------|-----------------------------|
-| type | string |
-| default | null |
+| name | value |
+| ------- | ------ |
+| type | string |
+| default | null |
There are multiple cases where it can be useful to group multiple upgrades together. Internally Renovate uses this for branches such as "Pin Dependencies", "Lock File Maintenance", etc. Another example used previously is to group together all related `eslint` packages, or perhaps `angular` or `babel`. To enable grouping, you set the `groupName` field to something non-null.
@@ -256,10 +256,10 @@ There are multiple cases where it can be useful to group multiple upgrades toget
Slug to use in the branch name for groups.
-| name | value |
-|----------|-----------------------------|
-| type | string |
-| default | null |
+| name | value |
+| ------- | ------ |
+| type | string |
+| default | null |
By default, Renovate will "slugify" the groupName to determine the branch name. For example if you named your group "All eslint packages" then the branchName would be `renovate/all-eslint-packages`. If you wished to override this then you could set like this:
@@ -274,10 +274,10 @@ And then the branchName would be `renovate/eslint` instead.
Dependencies to ignore.
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | [] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | [] |
The `ignoreDeps` configuration field allows you to define a list of dependency names to be ignored by Renovate. Currently it supports only "exact match" dependency names and not any patterns. e.g. to ignore both `eslint` and `eslint-config-base` you would add this to your config:
@@ -291,10 +291,10 @@ You could also configure this using `packageRules`, especially if you need patte
Ignore npmrc files found in repository
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | false |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | false |
There may be times where an `.npmrc` file in your repository causes problems, such as during lock file generation. Set this to true and Renovate will ignore any `.npmrc` files it finds.
@@ -302,10 +302,10 @@ There may be times where an `.npmrc` file in your repository causes problems, su
Ignore package files matching any of these paths
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | ['node_modules'] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | ['node_modules'] |
Using this setting, you can selectively ignore package files that you don't want Renovate autodiscovering. For instance if your repository has an "examples" directory of many package.json files that you don't want kept up to date.
@@ -313,21 +313,21 @@ Using this setting, you can selectively ignore package files that you don't want
Ignore versions with unstable semver.
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | true |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | true |
-By default, Renovate won't update any packages to unstable versions (e.g. `4.0.0-rc3`) unless the package version was *already* unstable (e.g. it was already on `4.0.0-rc2`). If for some reason you wish to *force* unstable updates on Renovate, you can set `ignoreUnstable` to `false`, but this is not recommended for most situations.
+By default, Renovate won't update any packages to unstable versions (e.g. `4.0.0-rc3`) unless the package version was _already_ unstable (e.g. it was already on `4.0.0-rc2`). If for some reason you wish to _force_ unstable updates on Renovate, you can set `ignoreUnstable` to `false`, but this is not recommended for most situations.
## labels
Labels to add to Pull Requests
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | [] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | [] |
Add an array of 1 or more strings to `labels` and Renovate will apply these labels to any PR its created. Usually these will be a per-repository setting like "renovate", or "ready", or "dependencies", however you can configure them right down to per-package level.
@@ -335,10 +335,10 @@ Add an array of 1 or more strings to `labels` and Renovate will apply these labe
Use group names only when more than one upgrade is available.
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | true |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | true |
The default behaviour for Renovate is to only use group names for branches and PRs when there's more than one dependency in a group. For example you may have defined a dependency group calls "All eslint packages" with a `packagePattern` of `^eslint`, but if the only upgrade available at the time is `eslint-config-airbnb` then it makes more sense for the PR to be named "Upgrade eslint-config-airbnb to version 2.1.4" than to name it "Upgrade All eslint packages". If ever this behaviour is undesirable then you can override it by setting this option to `false`.
@@ -346,10 +346,10 @@ The default behaviour for Renovate is to only use group names for branches and P
Configuration for lock file maintenance.
-| name | value |
-|----------|-----------------------------|
-| type | configuration object |
-| default | {% raw %}{<br /> "enabled": true,<br /> "recreateClosed": true,<br /> "branchName": "renovate/lock-files",<br /> "commitMessage": "{{semanticPrefix}}Update lock file",<br /> "prTitle": "{{semanticPrefix}}Lock file maintenance",<br /> "prBody": "This PR regenerates lock files to keep them up-to-date.",<br /> "schedule": ["before 5am on monday"]<br />}{% endraw %} |
+| name | value |
+| ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| type | configuration object |
+| default | {% raw %}{<br /> "enabled": true,<br /> "recreateClosed": true,<br /> "branchName": "renovate/lock-files",<br /> "commitMessage": "{{semanticPrefix}}Update lock file",<br /> "prTitle": "{{semanticPrefix}}Lock file maintenance",<br /> "prBody": "This PR regenerates lock files to keep them up-to-date.",<br /> "schedule": ["before 5am on monday"]<br />}{% endraw %} |
By setting enabled=true, this means that the default behaviour is to "maintain" lock files for each `package.json` if they exist already. "Maintaining" a lock file means recreating it to get an up-to-date version and committing that. Supported lock files include `package-lock.json` (npm >= 5) and `yarn.lock` (yarn).
@@ -369,10 +369,10 @@ The `recreateClosed` setting is necessary to tell Renovate to override its defau
Configuration specific for major dependency updates.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | {} |
+| name | value |
+| ------- | ------ |
+| type | object |
+| default | {} |
Add to this object if you wish to define rules that apply only to major updates.
@@ -380,10 +380,10 @@ Add to this object if you wish to define rules that apply only to major updates.
Configuration specific for meteor updates.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | { enabled: false } |
+| name | value |
+| ------- | ------------------ |
+| type | object |
+| default | { enabled: false } |
Set enabled to `true` to enable meteor package updating.
@@ -391,10 +391,10 @@ Set enabled to `true` to enable meteor package updating.
Configuration specific for minor dependency updates.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | {} |
+| name | value |
+| ------- | ------ |
+| type | object |
+| default | {} |
Add to this object if you wish to define rules that apply only to minor updates.
@@ -402,10 +402,10 @@ Add to this object if you wish to define rules that apply only to minor updates.
A string copy of npmrc file.
-| name | value |
-|----------|-----------------------------|
-| type | string |
-| default | null |
+| name | value |
+| ------- | ------ |
+| type | string |
+| default | null |
See http://localhost:4000/docs/deep-dives/private-modules for details on how this is used.
@@ -413,10 +413,10 @@ See http://localhost:4000/docs/deep-dives/private-modules for details on how thi
Your npmjs token.
-| name | value |
-|----------|-----------------------------|
-| type | string |
-| default | null |
+| name | value |
+| ------- | ------ |
+| type | string |
+| default | null |
See http://localhost:4000/docs/deep-dives/private-modules for details on how this is used. Typically you would encrypt it and put it inside the `encrypted` object.
@@ -424,10 +424,10 @@ See http://localhost:4000/docs/deep-dives/private-modules for details on how thi
Configuration specific for `package.json > optionalDependencies`.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | {} |
+| name | value |
+| ------- | ------ |
+| type | object |
+| default | {} |
Extend this if you wish to configure rules specificly for `optionalDependencies` and not `dependencies` or `devDependencies`.
@@ -435,10 +435,10 @@ Extend this if you wish to configure rules specificly for `optionalDependencies`
A manually provisioned list of package.json paths to use.
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | `[]` |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | `[]` |
If left default then package file autodiscovery will be used, so only change this setting if you wish to manually specify a limited set of `package.json` files to renovate, or if package file autodiscovery is not finding all your `package.json` files.
@@ -448,10 +448,10 @@ Note: `package.json` autodiscovery works for any GitHub repository that isn't it
A list of package names inside a package rule.
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | [] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | [] |
Use this field if you want to have one or more exact name matches in your package rule. See also `excludedPackageNames`.
@@ -459,10 +459,10 @@ Use this field if you want to have one or more exact name matches in your packag
A list of package patterns inside a package rule.
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | [] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | [] |
Use this field if you want to have one or more package names patterns in your package rule. See also `excludedPackagePatterns`.
@@ -470,10 +470,10 @@ Use this field if you want to have one or more package names patterns in your pa
A list of package rules to apply.
-| name | value |
-|----------|-----------------------------|
-| type | list of configuration objects |
-| default | [] |
+| name | value |
+| ------- | ----------------------------- |
+| type | list of configuration objects |
+| default | [] |
`packageRules` is a powerful feature that lets you apply rules to individual packages or to groups of packages using regex pattern matching.
@@ -501,7 +501,7 @@ Here is an example where you might want to limit the "noisy" package `aws-sdk` t
]
```
-Note how the above uses `packageNames` instead of `packagePatterns` because it is an exact match package name. This is the equivalent of defining `"packagePatterns": ["^aws\-sdk$"]` and hence much simpler. However you can mix together both `packageNames` and `packagePatterns` in the same package rule and the rule will be applied if *either* match. Example:
+Note how the above uses `packageNames` instead of `packagePatterns` because it is an exact match package name. This is the equivalent of defining `"packagePatterns": ["^aws\-sdk$"]` and hence much simpler. However you can mix together both `packageNames` and `packagePatterns` in the same package rule and the rule will be applied if _either_ match. Example:
```json
"packageRules": [
@@ -519,10 +519,10 @@ The above rule will group together the `neutrino` package and any package matchi
Configuration specific for patch dependency updates.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | { "branchName": "{{branchPrefix}}{{depName}}-{{newVersionMajor}}.{{newVersionMinor}}.x" } |
+| name | value |
+| ------- | ----------------------------------------------------------------------------------------- |
+| type | object |
+| default | { "branchName": "{{branchPrefix}}{{depName}}-{{newVersionMajor}}.{{newVersionMinor}}.x" } |
Add to this object if you wish to define rules that apply only to patch updates. See also `major` and `minor` configuration options.
@@ -530,10 +530,10 @@ Add to this object if you wish to define rules that apply only to patch updates.
Configuration specific for `package.json > peerDependencies`.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | {"enabled": false} |
+| name | value |
+| ------- | ------------------ |
+| type | object |
+| default | {"enabled": false} |
Extend this if you wish to configure rules specifically for `peerDependencies`. Disabled by default.
@@ -541,10 +541,10 @@ Extend this if you wish to configure rules specifically for `peerDependencies`.
Configuration specific for dependency pinning.
-| name | value |
-|----------|-----------------------------|
-| type | object |
-| default | {<br />"automerge": true,<br />"unpublishSafe": false,<br />"groupName": "Pin Dependencies",<br />"group": {"prTitle": "{{groupName}}", "semanticPrefix": "refactor(deps):"}<br />} |
+| name | value |
+| ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| type | object |
+| default | {<br />"automerge": true,<br />"unpublishSafe": false,<br />"groupName": "Pin Dependencies",<br />"group": {"prTitle": "{{groupName}}", "semanticPrefix": "refactor(deps):"}<br />} |
Add to this object if you wish to define rules that apply only to PRs that pin dependencies.
@@ -552,10 +552,10 @@ Add to this object if you wish to define rules that apply only to PRs that pin d
Whether to convert ranged versions in `package.json` to pinned versions.
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | true |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | true |
This is a very important feature to consider, because not every repository's requirements are the same. Although Renovate's default value for pinVersions is `true` - i.e. pin versions of all dependencies, there are cases where you may want to keep ranges, for example if your project is a web library that is consumed by others. In that case, you may wish to keep ranges for `dependencies` but pin versions for `devDependencies`, for example.
@@ -565,10 +565,10 @@ When creating the onboarding PR, Renovate will try to detect the best setting fo
Pull Request body template.
-| name | value |
-|----------|-----------------------------|
-| type | handlebars template |
-| default | [too long or inclusion] |
+| name | value |
+| ------- | ----------------------- |
+| type | handlebars template |
+| default | [too long or inclusion] |
Although the PR body can be customised by you, it might be quite challenging. If you think the Pull Request should include different information or could be formatted better, perhaps try raising an [Issue](https://github.com/renovateapp/renovate/issues) and let us solve it for you and for everyone else too.
@@ -576,17 +576,17 @@ Although the PR body can be customised by you, it might be quite challenging. If
When to create the PR for a branch.
-| name | value |
-|----------|-----------------------------|
-| type | string |
-| valid values | "immediate", "not-pending", "status-success" |
-| default | "immediate" |
+| name | value |
+| ------------ | -------------------------------------------- |
+| type | string |
+| valid values | "immediate", "not-pending", "status-success" |
+| default | "immediate" |
This setting tells Renovate when you would like it to raise PRs:
-- `immediate` (default): Renovate will create PRs immediately after creating the corresponding branch
-- `not-pending`: Renovate will wait until status checks have completed (passed or failed) before raising the PR
-- `status-success`: Renovate won't raise PRs unless tests pass
+* `immediate` (default): Renovate will create PRs immediately after creating the corresponding branch
+* `not-pending`: Renovate will wait until status checks have completed (passed or failed) before raising the PR
+* `status-success`: Renovate won't raise PRs unless tests pass
Renovate defaults to `immediate` but some like to change to `not-pending`. If you set to immediate, it means you will usually get GitHub notifications that a new PR is available but if you view it immediately then it will still have "pending" tests so you can't take any action. With `not-pending`, it means that when you receive the PR notification, you can see if it passed or failed and take action immediately. Therefore you can customise this setting if you wish to be notified a little later in order to reduce "noise".
@@ -594,10 +594,10 @@ Renovate defaults to `immediate` but some like to change to `not-pending`. If yo
Pull Request title template
-| name | value |
-|----------|-----------------------------|
-| type | handlebars template |
-| default | {% raw %}{{semanticPrefix}}{{#if isPin}}Pin{{else}}Update{{/if}} dependency {{depName}} to version {{#if isRange}}{{newVersion}}{{else}}{{#if isMajor}}{{newVersionMajor}}.x{{else}}{{newVersion}}{{/if}}{{/if}}{% endraw %} |
+| name | value |
+| ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| type | handlebars template |
+| default | {% raw %}{{semanticPrefix}}{{#if isPin}}Pin{{else}}Update{{/if}} dependency {{depName}} to version {{#if isRange}}{{newVersion}}{{else}}{{#if isMajor}}{{newVersionMajor}}.x{{else}}{{newVersion}}{{/if}}{{/if}}{% endraw %} |
The PR title is important for some of Renovate's matching algorithms (e.g. determining whether to recreate a PR or not) so ideally don't modify it much.
@@ -605,10 +605,10 @@ The PR title is important for some of Renovate's matching algorithms (e.g. deter
Whether to rebase branches that are no longer up-to-date with the base branch.
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | false |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | false |
This field is defaulted to `false` because it has a potential to create a lot of noise and additional builds to your repository. If you enable it, it means each Renovate branch will be updated whenever the base branch has changed. If enabled, this also means that whenever a Renovate PR is merged (whether by automerge or manually via GitHub web) then any other existing Renovate PRs will then need to get rebased and retested.
@@ -616,16 +616,16 @@ This field is defaulted to `false` because it has a potential to create a lot of
Recreate PRs even if same ones were closed previously.
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | false |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | false |
By default, Renovate will detect if it has proposed an update to a project before and not propose the same one again. For example the Webpack 3.x case described above. This field lets you customise this behaviour down to a per-package level. For example we override it to `true` in the following cases where branch names and PR titles need to be reused:
-- Package groups
-- When pinning versions
-- Lock file maintenance
+* Package groups
+* When pinning versions
+* Lock file maintenance
Typically you shouldn't need to modify this setting.
@@ -633,10 +633,10 @@ Typically you shouldn't need to modify this setting.
List of status checks that must pass before automerging.
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | [] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | [] |
This is a future feature that is partially implemented. Currently Renovate's default behaviour is to only automerge if every status check has succeeded. In future, this might be configurable to allow certain status checks to be ignored.
@@ -644,10 +644,10 @@ You can still override this to `null` today if your repository doesn't support s
## respectLatest
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | true |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | true |
Similar to `ignoreUnstable`, this option controls whether to update to versions that are greater than the version tagged as `latest` in the repository. By default, `renovate` will update to a version greater than `latest` only if the current version is itself past latest.
@@ -655,10 +655,10 @@ Similar to `ignoreUnstable`, this option controls whether to update to versions
Requested reviewers for Pull Requests
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | [] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | [] |
Must be valid usernames.
@@ -666,10 +666,10 @@ Must be valid usernames.
Times of day/week to schedule Renovate updates.
-| name | value |
-|----------|-----------------------------|
-| type | array of strings |
-| default | [] |
+| name | value |
+| ------- | ---------------- |
+| type | array of strings |
+| default | [] |
The `schedule` option allows you to define 1 or more times of week for Renovate updates. Running Renovate around the clock may seem too "noisy" for some projects and therefore `schedule` is a good way to reduce the noise by reducing the timeframe in which Renovate will operate on your repository.
@@ -710,23 +710,23 @@ To restrict `aws-sdk` to only weekly updates, you could add this package rule:
Enable semantic commit prefixes for commits and PR titles.
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | null |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | null |
If you are using a semantic prefix for your commits, then you will want to enable this setting. Although it's configurable to a package-level, it makes most sense to configure it at a repository level. If set to true, then the `semanticPrefix` field will be used for each commit message and PR title.
-However, please note that Renovate will autodetect if your repository is already using semantic commits or not and follow suit, so you only really need to configure this if you wish to *override* Renovate's autodetected setting.
+However, please note that Renovate will autodetect if your repository is already using semantic commits or not and follow suit, so you only really need to configure this if you wish to _override_ Renovate's autodetected setting.
## semanticPrefix
Prefix to use if semantic commits are enabled.
-| name | value |
-|----------|-----------------------------|
-| type | string |
-| default | "chore(deps): " |
+| name | value |
+| ------- | --------------- |
+| type | string |
+| default | "chore(deps): " |
By default, Renovate uses `angular` semantic commit conventions and `chore(deps)` as the prefix. This is override for `dependencies`, which defaults to `fix(deps)`. You can change this setting by editing this `semanticPrefix` field at any configuration level.
@@ -734,34 +734,34 @@ By default, Renovate uses `angular` semantic commit conventions and `chore(deps)
If set to false, it will upgrade dependencies to latest release only, and not separate major/minor branches.
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | true |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | true |
Renovate's default behaviour is to create a separate branch/PR if updates or multiple major versions exist. For example, if you were using Webpack 2.0.0 and versions 2.1.0 and 3.0.0 were both available, then Renovate would create two PRs so that you have the choice whether to apply the minor update to 2.x or the major update of 3.x. If you were to apply the minor update then Renovate would keep updating the 3.x branch for you as well, e.g. if Webpack 3.0.1 or 3.1.0 were released. If instead you applied the 3.0.0 update then Renovate would clean up the unneeded 2.x branch for you on the next run.
-It is recommended that you leave this setting to true, because of the polite way that Renovate handles this. For example, let's say in the above example that you decided you wouldn't update to Webpack 3 for a long time and don't want to build/test every time a new 3.x version arrives. In that case, simply close the "Update Webpack to version 3.x" PR and it *won't* be recreated again even if subsequent Webpack 3.x versions are released. You can continue with Webpack 2.x for as long as you want and receive any updates/patches that are made for it. Then eventually when you do want to update to Webpack 3.x you can make that update to `package.json` yourself and commit it to master once it's tested. After that, Renovate will resume providing you updates to 3.x again! i.e. if you close a major upgrade PR then it won't come back again, but once you make the major upgrade yourself then Renovate will resume providing you with minor or patch updates.
+It is recommended that you leave this setting to true, because of the polite way that Renovate handles this. For example, let's say in the above example that you decided you wouldn't update to Webpack 3 for a long time and don't want to build/test every time a new 3.x version arrives. In that case, simply close the "Update Webpack to version 3.x" PR and it _won't_ be recreated again even if subsequent Webpack 3.x versions are released. You can continue with Webpack 2.x for as long as you want and receive any updates/patches that are made for it. Then eventually when you do want to update to Webpack 3.x you can make that update to `package.json` yourself and commit it to master once it's tested. After that, Renovate will resume providing you updates to 3.x again! i.e. if you close a major upgrade PR then it won't come back again, but once you make the major upgrade yourself then Renovate will resume providing you with minor or patch updates.
## separatePatchReleases
If set to true, it will separate minor and patch updates into separate branches.
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | false |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | false |
-By default, Renovate won't distinguish between "patch" (e.g. 1.0.x) and "minor" (e.g. 1.x.0) releases - groups them together. e.g. if you are running version 1.0.0 of a package and both versions 1.0.1 and 1.1.0 are available then Renovate will raise a single PR for version 1.1.0. If you wish to distinguish between patch and minor upgrades, for example if you wish to automerge patch but not minor, then you can set this option to `true`.
+By default, Renovate won't distinguish between "patch" (e.g. 1.0.x) and "minor" (e.g. 1.x.0) releases - groups them together. e.g. if you are running version 1.0.0 of a package and both versions 1.0.1 and 1.1.0 are available then Renovate will raise a single PR for version 1.1.0. If you wish to distinguish between patch and minor upgrades, for example if you wish to automerge patch but not minor, then you can set this option to `true`.
## timezone
[IANA Time Zone](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) for the repository.
-| name | value |
-|----------|-----------------------------|
-| type | string |
-| default | `Etc/UTC` |
+| name | value |
+| ------- | --------- |
+| type | string |
+| default | `Etc/UTC` |
It is only recommended to set this field if you wish to use the `schedules` feature and want to write them in your local timezone. Please see the above link for valid timezone names.
@@ -769,20 +769,20 @@ It is only recommended to set this field if you wish to use the `schedules` feat
Set a status check for unpublish-safe upgrades.
-| name | value |
-|----------|-----------------------------|
-| type | boolean |
-| default | false |
+| name | value |
+| ------- | ------- |
+| type | boolean |
+| default | false |
-It is not known by many that npm package authors and collaborators can *delete* an npm version if it is less than 24 hours old. e.g. version 1.0.0 might exist, then version 1.1.0 is released, and then version 1.1.0 might get deleted hours later. This means that version 1.1.0 essentially "disappears" and 1.0.0 returns to being the "latest". If you have installed 1.1.0 during that time then your build is essentially broken.
+It is not known by many that npm package authors and collaborators can _delete_ an npm version if it is less than 24 hours old. e.g. version 1.0.0 might exist, then version 1.1.0 is released, and then version 1.1.0 might get deleted hours later. This means that version 1.1.0 essentially "disappears" and 1.0.0 returns to being the "latest". If you have installed 1.1.0 during that time then your build is essentially broken.
-This setting `unpublishSafe` enabled will add a `renovate/unpublish-safe` status check with value pending to every branch to warn you about this possibility. It can be handy when used with the `prCreation` = `not-pending` configuration option - that way you won't get the PR raised until after a patch is 24 hours old or more.
+This setting `unpublishSafe` enabled will add a `renovate/unpublish-safe` status check with value pending to every branch to warn you about this possibility. It can be handy when used with the `prCreation` = `not-pending` configuration option - that way you won't get the PR raised until after a patch is 24 hours old or more.
## yarnrc
A string copy of yarnrc file.
-| name | value |
-|----------|-----------------------------|
-| type | string |
-| default | null |
+| name | value |
+| ------- | ------ |
+| type | string |
+| default | null |
diff --git a/website/docs/_posts/2017-10-06-noise-reduction.md b/website/docs/_posts/2017-10-06-noise-reduction.md
index c6bb7b37cd405f739bd54eca86335d8921c4ef8b..12ebb5360a2a914a499514d54280b3e3c88de0e4 100644
--- a/website/docs/_posts/2017-10-06-noise-reduction.md
+++ b/website/docs/_posts/2017-10-06-noise-reduction.md
@@ -91,9 +91,9 @@ For example, if you have `jest` or `mocha` as a dependency, and it has an upgrad
Those of you familiar with GitHub might note that even if you automerge PRs, you are still going to get notifications (noise) anyway - one when the PR is created and another when it is merged. For this reason we recommend you consider setting `automergeType=branch-push` which will mean:
-- Renovate first creates a branch and no PR
-- If tests pass, Renovate pushes a commit directly to `master` without PR
-- If tests fail, Renovate raises a PR for you to review
+* Renovate first creates a branch and no PR
+* If tests pass, Renovate pushes a commit directly to `master` without PR
+* If tests fail, Renovate raises a PR for you to review
The result is that passing updates are essentially "silent" - the only sign of them are the commits to your `master` branch.
@@ -101,12 +101,12 @@ The result is that passing updates are essentially "silent" - the only sign of t
Automerging is particularly beneficial if you have configured a schedule, because Renovate on its own may be able to automerge the majority of your updates. And this is especially so if your repository needs rebasing, e.g. because you use lock files. e.g. let's say you have dependencies `abc` and `xyz` with upgrades, and you use a `yarn.lock` file.
-- At start of schedule, `Renovate` will create branches for `abc` and `xyz` upgrades, including `yarn.lock` updates
-- After `abc` passes tests, `Renovate` will automerge it to `master`
-- The `xyz` branch probably now has `yarn.lock` conflicts
-- Renovate will immediately check all other branches and rebase them
-- The change to `xyz` branch will trigger another round of CI tests
-- After the updated `xyz` branch passes, Renovate will automerge it too
+* At start of schedule, `Renovate` will create branches for `abc` and `xyz` upgrades, including `yarn.lock` updates
+* After `abc` passes tests, `Renovate` will automerge it to `master`
+* The `xyz` branch probably now has `yarn.lock` conflicts
+* Renovate will immediately check all other branches and rebase them
+* The change to `xyz` branch will trigger another round of CI tests
+* After the updated `xyz` branch passes, Renovate will automerge it too
This is a lot better than you waking up to two PRs and then having to deal with conflicts yourself after you merge the first one.
@@ -130,9 +130,9 @@ Have you come up with a rule that you think others would benefit from? How about
As mentioned earlier. using lock files greatly increase the chance that merging one PR will result in a second PR becoming conflicted with `master`. Therefore:
-- The more groups you use, the separate PRs you have, and hence the less overall chance at lock file conflicts
-- The less your schedule, the more chance that you pile up concurrent PRs, which increases the chance of lock file conflicts
-- The more automerging you do, the less chance you have concurrent PRs, which decreases the chance of lock file conflicts
+* The more groups you use, the separate PRs you have, and hence the less overall chance at lock file conflicts
+* The less your schedule, the more chance that you pile up concurrent PRs, which increases the chance of lock file conflicts
+* The more automerging you do, the less chance you have concurrent PRs, which decreases the chance of lock file conflicts
## The Future of Noise Reduction
@@ -141,4 +141,4 @@ First of all, if you every have any ideas about how to make Renovate less noisy,
1. Nearly everyone should probably use Renovate-like dependency update automation
2. Over time, you should "see" Renovate less and less
-One of our hopes with preset configs is that a set of "sensible" configs can be maintained by the community that combine grouping, scheduling and automerging to reduce the amount of noise in repositories with little downside or increased risk. Such lists could be maintained and used somewhat like Adblock lists - kept up to date by maintainers but for the majority of users they are simply trusted/automatic/invisible.
+One of our hopes with preset configs is that a set of "sensible" configs can be maintained by the community that combine grouping, scheduling and automerging to reduce the amount of noise in repositories with little downside or increased risk. Such lists could be maintained and used somewhat like Adblock lists - kept up to date by maintainers but for the majority of users they are simply trusted/automatic/invisible.
diff --git a/website/docs/_posts/2017-10-24-docker-support.md b/website/docs/_posts/2017-10-24-docker-support.md
index 41d8318366a5a5e7a55477ea04c0ad75b8533cfa..67fd2238debe8868a4885bf879bebe85bd5353e9 100644
--- a/website/docs/_posts/2017-10-24-docker-support.md
+++ b/website/docs/_posts/2017-10-24-docker-support.md
@@ -12,19 +12,19 @@ Renovate now supports updating Dockerfile `FROM` sources.
## Docker image digests
-One important way that Docker registries differ from npm is that Docker users mostly reference *tags*, and tags are not immutable, meaning that not only might (will) the `node:8` tag change (i.e. what you get today with a Docker pull is not the same as you might get tomorrow) but also tags that look like full versions (e.g. `node:8.7.0`) may also change, if the image publisher wishes to do so. Whereas in npm, a fully specified version is always immutable and won't change on you one day (whether accidentally, deliberately, or maliciously).
+One important way that Docker registries differ from npm is that Docker users mostly reference _tags_, and tags are not immutable, meaning that not only might (will) the `node:8` tag change (i.e. what you get today with a Docker pull is not the same as you might get tomorrow) but also tags that look like full versions (e.g. `node:8.7.0`) may also change, if the image publisher wishes to do so. Whereas in npm, a fully specified version is always immutable and won't change on you one day (whether accidentally, deliberately, or maliciously).
-Docker registries do support immutable tags in the form of *digests*. Instead of using a tag like `selenium/node-chrome:3.6.0` you can instead use `selenium/node-chrome@sha256:d99b4622b4329bbb563fd1b66c7f6e4b3255394112cb369ca12c8cdc631bc689`. This way you are guaranteed the underlying image won't change, but it's not really human-friendly.
+Docker registries do support immutable tags in the form of _digests_. Instead of using a tag like `selenium/node-chrome:3.6.0` you can instead use `selenium/node-chrome@sha256:d99b4622b4329bbb563fd1b66c7f6e4b3255394112cb369ca12c8cdc631bc689`. This way you are guaranteed the underlying image won't change, but it's not really human-friendly.
The good news is that it doesn't really need to be human-friendly if humans no longer have to update these FROM lines by hand, and instead use Renovate. <ore good news is that Docker does actually allow you to use both a tag and digest in a FROM line to make it more human-friendly, even if the tag is completely ignored. i.e. you can actually use `selenium/node-chrome:3.6.0@sha256:d99b4622b4329bbb563fd1b66c7f6e4b3255394112cb369ca12c8cdc631bc689`.
## Pin digests
-Renovate's default behaviour is therefore to "pin" digests, so that any changes to the underlying image that you pull is therefore deliberate, traceable and revertible.
+Renovate's default behaviour is therefore to "pin" digests, so that any changes to the underlying image that you pull is therefore deliberate, traceable and revertible.
If you use a plain image name without tag, e.g. `node`, it will be updated to `node@latest:sha256:...................`.
-If you use an image name with tag, the digest will be added. e.g. `node:8.7.0` will become `node:8.7.0@sha256:...................` or `node:8` will become `node:8@sha256:...................`.
+If you use an image name with tag, the digest will be added. e.g. `node:8.7.0` will become `node:8.7.0@sha256:...................` or `node:8` will become `node:8@sha256:...................`.
If you prefer to avoid using digests altogether, you can add `"pinDigests": false` to your `renovate.json` config.
@@ -32,11 +32,11 @@ If you prefer to avoid using digests altogether, you can add `"pinDigests": fals
Once you have pinned digests to your image/tag source, Renovate will keep checking if that tag has a new digest available and raise PRs accordingly.
-Therefore you'll still *get* updates for your desired tags as they're available, but instead of them appearing unannounced and potentially breaking your Docker image, instead they will appear as Renovate Pull Requests so that you are aware that something changed and can accept or reject accordingly.
+Therefore you'll still _get_ updates for your desired tags as they're available, but instead of them appearing unannounced and potentially breaking your Docker image, instead they will appear as Renovate Pull Requests so that you are aware that something changed and can accept or reject accordingly.
## Version updating
-Renovate also now supports *upgrading* tags, if those tags include a recognisable semver-like scheme.
+Renovate also now supports _upgrading_ tags, if those tags include a recognisable semver-like scheme.
For example, `node:6.10` would receive PRs for `node:6.11` and `node:8.7`. Or `node:8.7.0` would receive a PR for `node:8.7.1` if/once it's released. This is supported in addition to the digest updating behaviour described above, although digests have been left off these examples for brevity.
@@ -48,12 +48,12 @@ Version updating is not enabled by default in Renovate currently. If you wish to
Note the current caveats:
-- There is no way to turn off the suffix matching (e.g. `-onbuild`) so if someone tagged images like `4.0.0-alpha.1` then you will not receive a PR for `4.0.0-alpha.2` as that would be considered a different suffix.
+* There is no way to turn off the suffix matching (e.g. `-onbuild`) so if someone tagged images like `4.0.0-alpha.1` then you will not receive a PR for `4.0.0-alpha.2` as that would be considered a different suffix.
-- Renovate cannot yet differentiate between stable and unstable based on version numbers, e.g. if you run `node:6` then you will get offered `node:7` in additional `node:8` as Renovate doesn't know that odd numbers mean unstable
+* Renovate cannot yet differentiate between stable and unstable based on version numbers, e.g. if you run `node:6` then you will get offered `node:7` in additional `node:8` as Renovate doesn't know that odd numbers mean unstable
-- Renovate has no rules for LTS vs non-LTS, e.g. it will propose `node:8` as an upgrade to `node:6` even if `node:6` is LTS while `node:8` is just stable
+* Renovate has no rules for LTS vs non-LTS, e.g. it will propose `node:8` as an upgrade to `node:6` even if `node:6` is LTS while `node:8` is just stable
-- Similar caveats with `ubuntu`, e.g. it might propose `17.04` as an upgrade from `16.04`
+* Similar caveats with `ubuntu`, e.g. it might propose `17.04` as an upgrade from `16.04`
-Mostly these caveats are harmless, i.e. you can simply close any unwanted upgrades and they won't be suggested again.
\ No newline at end of file
+Mostly these caveats are harmless, i.e. you can simply close any unwanted upgrades and they won't be suggested again.
diff --git a/website/docs/_posts/2017-11-10-docker.md b/website/docs/_posts/2017-11-10-docker.md
index 035d08c6e26c128d9ce0acd94820010d5ffef52d..afaa33498e1bf52cf0bd0b83807118d7fad0a3c9 100644
--- a/website/docs/_posts/2017-11-10-docker.md
+++ b/website/docs/_posts/2017-11-10-docker.md
@@ -15,13 +15,13 @@ Renovate supports upgrading dependencies in Docker's `Dockerfile` files.
1. Renovate will search each repository for any files named (exactly) `Dockerfile`
2. The first `FROM` line will parsed
3. If no [digest](https://docs.docker.com/engine/reference/commandline/images/) is already in use then Renovate will raise a PR to "pin" that dependency to a Docker digest
-4. If the image tag in use "looks" like a semver (e.g. `node:8`, `node:8.9`, `node:8.9.0`, `node:8-onbuild`) then Renovate will look up the Docker registry to determine if any upgrades are available (e.g. `node:8.9.1`).
+4. If the image tag in use "looks" like a semver (e.g. `node:8`, `node:8.9`, `node:8.9.0`, `node:8-onbuild`) then Renovate will look up the Docker registry to determine if any upgrades are available (e.g. `node:8.9.1`).
## Digest Pinning
Pinning your docker images to an exact digest is important for reasons of **immutability**. In short: so every time you `pull`, you get the same content.
-If your experience with dependency versioning comes from a place like javascript/npm, you might be used to knowing that exact versions are immutable, e.g. if you specify a version like `2.0.1` then you and your colleagues will always get the exact same "code". What you may not expect is that Docker's tags are not immutable versions even if they look like a version. e.g. you probably expect that `node:8` and `node:8.9` will change over time, but you might incorrectly assume that `node:8.9.0` would never change. Although it probably *shouldn't*, the reality is that it *can*.
+If your experience with dependency versioning comes from a place like javascript/npm, you might be used to knowing that exact versions are immutable, e.g. if you specify a version like `2.0.1` then you and your colleagues will always get the exact same "code". What you may not expect is that Docker's tags are not immutable versions even if they look like a version. e.g. you probably expect that `node:8` and `node:8.9` will change over time, but you might incorrectly assume that `node:8.9.0` would never change. Although it probably _shouldn't_, the reality is that it _can_.
Using a docker digest as the image's primary identifier instead of docker tag will achieve immutability but as a human it's quite inconvenient to deal with strings like `FROM node@sha256:552348163f074034ae75643c01e0ba301af936a898d778bb4fc16062917d0430`. The good news is that, as a human you no longer need to manually update such digests once you have Renovate on the job.
@@ -29,7 +29,7 @@ Also, to retain some human-friendliness, Renovate will actually retain the tag i
## Digest Updating
-If you have followed our advice to go from tags like `node:8` to `node:8@sha256:552348163f074034ae75643c01e0ba301af936a898d778bb4fc16062917d0430`, then you are likely to receive Renovate PRs whenever the `node:8` image is updated on Docker Hub.
+If you have followed our advice to go from tags like `node:8` to `node:8@sha256:552348163f074034ae75643c01e0ba301af936a898d778bb4fc16062917d0430`, then you are likely to receive Renovate PRs whenever the `node:8` image is updated on Docker Hub.
Previously this would have been "invisible" to you - one day you pull code that represents `node:8.9.0` and the next day you get `node:8.9.1`. But you can never be sure, especially as Docker caches. Perhaps some of your colleagues or worst still your build machine are stuck on an older version with a security vulnerability.
@@ -37,7 +37,7 @@ Instead, you will now receive these updates via Pull Requests, or perhaps commit
## Version Upgrading
-Renovate also supports *upgrading* versions in Docker tags, e.g. from `node:8.9.0` to `node:8.9.1`. If your tags looks like a version, Renovate will upgrade it like a version.
+Renovate also supports _upgrading_ versions in Docker tags, e.g. from `node:8.9.0` to `node:8.9.1`. If your tags looks like a version, Renovate will upgrade it like a version.
Thanks to this, you may wish to change the way you tag your image dependencies to be more specific, e.g. change from `node:8` to `node:8.9.1` so that every Renovate PR will be more human friendly, e.g. you can know that you are getting a PR because `node` upgraded from `8.9.1` to `8.9.2` and not because `8.9.1` somehow changed.
@@ -45,8 +45,8 @@ Currently, Renovate will upgrade minor/patch versions (e.g. from `8.8` to `8.9`
Renovate has a some docker-specific intelligence when it comes to versions. For example:
-- It understands that tag suffixes are frequently used, such as `node:8.9-onbuild`. Renovate will only upgrade from/to the same suffix.
-- It understands that some dependencies (e.g. `node` and `ubuntu`) use even numbers for stable and odd for unstable. Renovate won't upgrade from stable unstable
+* It understands that tag suffixes are frequently used, such as `node:8.9-onbuild`. Renovate will only upgrade from/to the same suffix.
+* It understands that some dependencies (e.g. `node` and `ubuntu`) use even numbers for stable and odd for unstable. Renovate won't upgrade from stable unstable
## Configuring/Disabling
diff --git a/website/docs/_posts/2017-11-10-javascript.md b/website/docs/_posts/2017-11-10-javascript.md
index 7e36d9f94b186c7088b34203698633ccd65e1573..ce8e84fd6d0eb21a86b77236a289a705fef2ff4a 100644
--- a/website/docs/_posts/2017-11-10-javascript.md
+++ b/website/docs/_posts/2017-11-10-javascript.md
@@ -9,4 +9,3 @@ order: 1
---
Renovate supports upgrading JavaScript dependencies specified in `package.json` files.
-
diff --git a/website/docs/_posts/2017-12-05-node.md b/website/docs/_posts/2017-12-05-node.md
index 72c82ca86e6160b20eb6f3575f0f652b0a8d9882..b9366d1a278fd6d1ee40e64fca429d5609c0eabf 100644
--- a/website/docs/_posts/2017-12-05-node.md
+++ b/website/docs/_posts/2017-12-05-node.md
@@ -23,7 +23,7 @@ Renovate supports upgrading Node.js versions in `.travis.yml` files.
Renovate supports the following `supportPolicy` values and associated versions (current as of December 2017):
| supportPolicy | versions | description |
-|---------------|----------|-----------------------------------------------------------|
+| ------------- | -------- | --------------------------------------------------------- |
| lts | 4,6,8 | All releases classified as LTS, including in maintenance |
| active | 6,8,9 | All releases classified as active and not maintenance |
| current | 9 | The latest Node.js classified as "current" |
diff --git a/website/docs/_posts/2017-12-15-bazel.md b/website/docs/_posts/2017-12-15-bazel.md
index 027731b5015f5246a1073643bc01850281fa3b67..098f4bcbfcb5797fdb5a7c9dbdae1484c5d56219 100644
--- a/website/docs/_posts/2017-12-15-bazel.md
+++ b/website/docs/_posts/2017-12-15-bazel.md
@@ -13,9 +13,9 @@ Renovate supports upgrading dependencies in bazel `WORKSPACE` files.
## How It Works
1. Bazel support is enabled automatically, so you do not have to explicitly configure it to be enabled
-3. Renovate will search repositories for any `WORKSPACE` files in the repository
-4. Existing dependencies will be extracted from `git_repository` and `http_archive` declarations
-5. Renovate will replace any old versions with the latest version available
+2. Renovate will search repositories for any `WORKSPACE` files in the repository
+3. Existing dependencies will be extracted from `git_repository` and `http_archive` declarations
+4. Renovate will replace any old versions with the latest version available
## git_repository
@@ -26,6 +26,7 @@ Renovate will update any `git_repository` declaration that contains the followin
3. tag using a valid semver
Example:
+
```
git_repository(
name = "build_bazel_rules_typescript",
@@ -45,6 +46,7 @@ Renovate will update any `http_archive` declaration that contains the following:
3. sha256
Example:
+
```
http_archive(
name = "io_bazel_rules_go",