Previously if there were any “pin” updates then that would block all non-pin updates until the pin one was merged. However, this doesn’t make sense if the other PR is for an unrelated dependency.
Closes https://github.com/renovatebot/config-help/issues/64
Refactors template logic to test for isSingleVersion instead of the negative of isRange. This means that new values like `==1.2.0` in python will be presented as v1.2.0
Renovate now ignores any upgrades that are marked as deprecated, unless the current version is itself also deprecated. The new config option `ignoreDeprecated` can be set to false to disable this if necessary.
Closes#1988
Previously, deprecation warnings were done as part of dependency lookups, which were run concurrently. This meant the chance of duplicate issues was high, due to race conditions. Instead, raising the issues is done once all package are looked up, to ensure only one issue per manager/dependency. It also means we can list all of the affected package files, in case of a monorepo.
Closes#2224, Closes#2225
Refactors updateType logic so that a type of “bump” is returned when bumping versions within existing ranges, instead of minor or major. Updates that fall *outside* the existing range will continue to be labeled as minor or major as appropriate.
This value can now be used within packageRules, e.g.
```
“updateTypes”: [“bump”],
“labels”: [“bumped version only”]
```
Closes#1942
Refactors credentials/token handling to rely less on env variables and instead use an endpoints middleware for credentials handling.
First step towards #2105
When generating a branch’s config, iterate through all upgrades and set automerge=true for the branch only if all upgrades have automerge=true. Similarly, set canBeUnpublished=true if ANY upgrade can be unPublished.
Closes#1999
Manually finds and massages node updates in Docker, Docker Compose and Circle CI so that they should take on the same “renovate/node-8.x” style branch naming. The goal is to unify all node updates into a single branch.
Raises an additional log file warning whenever lock file errors persist for a day or longer. The idea of this is that temporary errors - e.g. caused by npmjs itself - should not disturb the user. 1 day seems like a reasonable time for multiple attemps to be made first, assuming it has been scheduled. Once this is tested in production for a little while and no unexpected problems, it will be converted to actually raise a config warning issue in the repo to get user attention.
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 fixes a race condition where if someone merged multiple PRs in a row then a renovation-in-progress would get confused and post a “PR has been edited” message to an already-merged PR.
Closes#2115
Adds config options force and forceCli. These cover the use case where a certain setting is desired to be forced by the bot admin, regardless of repository config, for example removing all configured schedules in order to force PR creation.
Closes#1731
This PR adds the feature of commenting on a failed automerge. It's done by adding a conditional in `lib/workers/branch/automerge.js` which, in case of receiving `failure` or `error` from the `getBranchStatus` function, returns the "branch status error" value. Another modification is in `lib/workers/branch/index.js`, which is an adition to the failure response of the `tryBranchAutomerge` function. The added functionality is the ability to add a comment to the PR which had a failure automerging. In case of receiving the aforementioned "branch status error" value, to the comment is appended a note which emphasize the fact that there're multiple failed status checks.
Closes#1934
