Adds new `ignoreScripts` config option. If set to true, managers such as npm and composer will skip running install scripts even if trustLevel is configured to high.
Closes#4567
I find it unclear what exactly is supported by Renovate in terms of parsing text for schedules. By looking at the code, I can see that it seems to use later.js which has good documentation. I've added a link to their documentation for people who want to know more.
This commit adds (back) support for GitLab's 'merge when pipeline succeeds'
feature. This feature needs to be enabled by bot owners explicitely because
of an possible race condition in current GitLab versions.
Closes#3265
With Renovate’s github platform code now using git for all file system operations, we need to tell Renovate which gitAuthor to use.
If you had already configured a gitAuthor in your bot config, you do not need to make any change.
Otherwise, to keep functionality as before, you should either:
(1) configure `gitAuthor` to match the bot’s account, or
(2) recreate your bot’s personal access token to include the “user:email” permission so that the bot can retrieve the email itself
BREAKING CHANGE: GitHub bot admins should either configure gitAuthor in their config or generate a new token with “user:email” permissions.
Deprecate use of “special” env var like `GITHUB_TOKEN` and instead standardize on `RENOVATE_*` environment variables instead.
Closes#2834
BREAKING CHANGE: For GitHub, GitLab, Bitbucket and VSTS you need to migrate `*_ENDPOINT` to `RENOVATE_ENDPOINT`, `*_TOKEN` to `RENOVATE_TOKEN`, and same for `BITBUCKET_USERNAME` and `BITBUCKET_PASSWORD`.
I haven’t used Heroku with Renovate in over a year and am not able to directly support it. I think it would be best to be made into a “wrapper” repository like https://github.com/renovatebot/renovate-heroku
BREAKING CHANGE: renovate repository no longer supports direct deployment to Heroku
This PR replaces the existing `pinVersions`, `upgradeInRange` and `versionStrategy` settings with a single one: `rangeStrategy`.
Previously:
- `pinVersions` could be `true` or `false`, but defaulted to `null`, which meant that Renovate would decide. `true` meant that Renovate would replace existing ranges like `^1.0.0` with an exact/pinned version such as `1.2.0`.
- `upgradeInRange` could be true or false, default to false. If `true`, it would mean Renovate would replace an existing range like `^1.0.0` with something like `^1.2.0`
- `versionStrategy` could be `replace` or `widen` and was mainly used for `peerDependencies` to widen existing ranges, e.g. from `^1.0.0` to `^1.0.0 || ^2.0.0`
It was possible to set conflicting settings, e.g. configuring `pinVersions=true` and `upgradeInRange=true`.
Now, we combine them into a single setting: `rangeStrategy`:
- `auto` = Renovate decides (this will be done on a manager-by-manager basis)
- `pin` = convert ranges to exact versions
- `bump` = same as `upgradeInRange` previously, e.g. bump the range even if the new version satisifies the existing range
- `replace` = Same as pinVersions === false && upgradeInRange === false, i.e. only replace the range if the new version falls outside it
- `widen` = Same as previous versionStrategy==='widen'
Renovate now comes with a variety of package managers supported, each with their own filename pattern(s). These patterns are now exposed for user configuration through the new `fileMatch` list/array configuration option, which has been added to each manager (npm, bazel, docker-compose, etc). `fileMatch` is defined as a mergeable list, meaning that users can add to the default pattern to extend the files being detected.
Closes#799
Rules for dep types (e.g. dependencies, devDependencies, peerDependencies, optionalDependencies) should now be done with `packageRules` and the `depTypeList` selector
