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
Adds basic support for renovating C# project files. The scope is initially limited to:
- .Csproj only (no VB.NET / F#)
- SDK style csproj's only (this is the default in .net core anyway)
- Limited to nuget.org support (no custom repository support)
Closes#935, Closes#2050
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
Added permission checking on `initRepo` which, in case of an error, throws a clear message (`The token doesn't have the write permissions to the repository`)
Closes#509
This PR follows up and fixes#1968
The previous PR didn't behave correctly as it was expecting Github Enterprise to ALWAYS been configured and that the github.com token was available in the `GITHUB_COM_TOKEN` env variable.
But for non GHE project `GITHUB_COM_TOKEN` is not defined and github.com token is available at the `GITHUB_TOKEN` env variable instead.
This updated PR fix this issue and avoid further problems by prioritising `github.com` over GHE.
Now the code is NOOP if no `GITHUB_ENDPOINT` is configured.
If it's configured, instead, now the codes assumes that, by DEFAULT, a dependency is hosted on `github.com` so it removes `GITHUB_ENDPOINT` and use `GITHUB_COM_TOKEN` as Github token immediately.
They are restored only if needed, when a dependency is hosted on the provided GithubEnterprise.
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'
This PR adds support for pip changelog,
unlike npm, I couldn't find a mapping between github and pip other than github being used as the homepage of some projects, if there are other ways of mapping it would be helpful.
Closes#1911
This PR splits the logic behind changelog into manager (npm) and source (github)
the manager provides the repo url + versions
the source consumes the manager info and generates changelog info
Closes#1911
Refactor changelog (commits) logic to separate sources, and remove the `changelog` dependency. Instead of a full copy/paste of commits, a link is now provided to the source repo.
Closes#381
The matchCurrentVersion option sets a range of versions that a package update can be in. If the package's current version doesn't satisfy the matchCurrentVersion range, it won't match the rule.
Closes#1771
This PR refactors `branchName`, `commitMessage` and `prTitle` so that they are more easily editable and hopefully more understandable. By breaking each up into subsections, users can modify one part without needing to copy/paste the entire string.
Directly editing any of these fields will now be deprecated and a warning issued.
Adds a field `depTypeList` to `packageRules`, enabling rules for packages to be applied for any `depType`. Config objects `dependencies`, `devDependencies` and `peerDependencies` will be deprecated in favour of this new approach.
Closes#1807
Changes the default onboarding config from `{ extends: [‘config:base’] }` to `{}` (empty). Self-hosted bot users can add it back by configuring `onboardingConfig` in `config.js` or env. Doing this makes the bot less “opinionated” by default and more convenient for self-hosted users, who can configured everything in config.js or env now.
Closes#1554
BREAKING CHANGE: onboarding config now defaults to empty config instead of config:base. Self-hosted users need to add it back if they with to retain it as default suggested config.
This hopefully gives a better chance of GitHub being able to finish computing the new mergeability status, and reduces the chance of a race condition.
Closes#1617
Improves changelog detection algorithm to look for different upper/lower case options as well as alternative filenames like `History.md`.
Resolves#1754
Adds an option “updateLockFiles” which defaults to true. Setting to false means that updating lock files (e.g. package-lock.json, yarn.lock and shrinkwrap.yaml) will be skipped. The main reason for doing this is for repositories that use a dependency we can’t resolve, so that they can keep updating the package.json without lock file.
