New config option replaces existing option exposeEnv. Set trustLevel=high in the bot config if you trust the contents of the repositories you are renovating. Doing so results in env being exposed, access to localhost, etc.
Closes#2739
This deprecates branch-push and branch-merge-commit automergeTypes and replaces with “branch”, which has the same behaviour as the previous branch-push.
BREAKING CHANGE: branch-merge-commit automergeType behaviour is no longer supported, all branch automerges now use branch push approach.
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'
Rules for dep types (e.g. dependencies, devDependencies, peerDependencies, optionalDependencies) should now be done with `packageRules` and the `depTypeList` selector
This PR adds the capability to renovate more than one base branch at a time. For instance, a project may have their released `3.x` version on `master`, while an upcoming `4.x` is being prepared using branch `next`. `4.x` might have a quite different set of dependencies (e.g. some removed or some added) so it's not appropriate to only target `master` and keep rebasing, as it will get messy. Instead, it's necessary to target both `master` and `next` to keep both updated.
Closes#1279