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.
`Adds a config validation check for timezone, checking it against the list in moment-timezome.js`. Configs with invalid timezones will raise a configuration error.
Closes#1483
Upgrade ranges to latest version even if latest version satisfies existing range.
| name | value |
| ------- | ------- |
| type | boolean |
| default | false |
By default, Renovate assumes that if you are using ranges then it's because you want them to be wide/open. As such, Renovate won't deliberately "narrow" the range by increasing the semver value inside.
For example, if your `package.json` specifies a value for `left-pad` of `^1.0.0` and the latest version on npmjs is `1.2.0`, then Renovate won't change anything. If instead you'd prefer to be updated to `^1.2.0` in cases like this, then set `upgradeInRange` to `true` in your Renovate config.
This feature supports simple caret (`^`) and tilde (`~`) ranges only, like `^1.0.0` and `~1.0.0`. It is not compatible with `pinVersions=true`.
Closes#1607
Before, we were attempting to rebase edited branches if renovate.json was the only modified file. This “lost” the committer information - which seemed ok - but it also meant that on the subsequent run it then assumed Renovate was the only committer. Now we don’t rebase edited onboarding branches anymore.
Closes#1360
Adds configuration option `onboardingConfig` that allows the default onboarding config to be extended or replaced via `config.js` or env configuration.
Closes#1521
* Revert "fix: disable reusing existing package-lock.json when upgrading (#1530)"
This reverts commit 2728e39963.
* switch from —package-lock-only to —ignore-scripts
Removing `--package-lock-only` option from npm installs due to https://github.com/npm/npm/issues/19852
Pretty sure this fixes#1495
Adds support for running `lerna bootstrap` instead of `npm install` or `yarn install` (without Workspaces), hence allowing support of internally-linked dependencies.
Closes#1441, Closes#1443
Detects and embeds release notes found on GitHub when an npm dependency specifies a GitHub repository as its source and that repository has made use of the "Releases" feature.
Adds a new feature to limit the number of concurrent branches/PRs to have open at any one time. Defaults to 0 (disabled), set it to a positive integer to enforce that limit.
If a packageRule is missing packageNames AND missing packagePatterns, then we should match by default. This allows users to define a single “exclude” rule without needing to add a catchall include rule (e.g. `packagePatterns”: [“.*”]`)
When package-lock.json or yarn.lock files are present, and Renovate needs to “pin” any dependencies (e.g. after onboarding), it will use whatever version is in the lockfile rather than the latest version on npm js that satisfies the semver range. This should increase the chance that Pin Dependencies PRs pass tests, as it should use as close as possible dependencies as the previous time the lock file was committed to master. Thanks to @alexeagle for first suggesting this.
Closes#1362
Adds a `renovate/verify` status check for those migrating and looking for familiarity. Better to check the GPG verified commit, as mentioned in the associated doc.
Adds new config option `versionStrategy` that allows config to override Renovate’s autodetection of when to “widen” an existing semver range, and when to “replace”.
Adds support for ranges, such as `”1.x - 2.x”`. Adds support for widening .x ranges, e.g. `”1.x || 2.x”` becomes updated to `”1.x || 2.x || 3.x”`.
Closes#687
Adds support for "less than" semver, and for complex semver values that end in "less than" e.g. ">= 1.0.0 < 2.0.0". Also supports complex semver values that end in "less than or equal to", although they make a lot less sense, e.g. ">= 1.0.0 <= 2.0.0".
Closes#1433
Changes the way Renovate treats renovate config inside `package.json` files. Before, config used to be applied only to that particular file, meaning that it was not applied for the rest of a monorepo, or for other package managers like Docker. Now, any `renovate` section inside the repository’s root `package.json` will be applied globally, just the sams as if it were contained within a `renovate.json` file. This means there is no longer any case where you *must* have a `renovate.json` file instead of `package.json`.
Closes#1323
BREAKING CHANGE: renovate config in `./package.json` is now applied to whole repository, and renovate config inside non-root `package.json` files is now ignored.
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
By stripping ‘types/ from the branch name, package x and @types/x then become automatically combined in the same PR. We then massage it a little to ensure the decription for the non-types package is used, and a note added saying that types is included.
Closes#1365
Previously, Renovate would attempt to keep a branch up to date even if users had edited it. e.g. adding commits on top of the existing branch if newer versions were released. Now, Renovate adds a warning comment if a user has edited a branch, making it clear that responsibility for the branch is over to them and how they can undo this.
Closes#653
When 404 or 422 errors are encountered writing updates, Renovate will now restart in an attempt to fix it. Usually this is because branches/PRs have been edited or closed while Renovate is running.
Closes#1299
To prevent PRs being opened prior to the `unpublishSafe` check having
transitioned from `pending` to `success`, when using `not-pending`
mode.
Fixes#1312.
This PR updates Renovate to detect config validation problems and (1) stop processing, and (2) either raise an Issue if already onboarded, or (2) update the onboarding PR to reflect the error if still onboarding.
Closes#1300
This PR adds the capability to run Renovate in a new "fork mode". This new mode must be configured by the Renovate admin, and cannot be configured within repositories themselves (for now). Example use: `renovate --autodiscover --fork-mode`
In this mode:
* Renovate will fork the repository if necessary (first run only)
* If the fork already existed, Renovate will ensure that its base branch is up to date with the source repository's
* Branches will be created within the fork, PRs will be created in the source
This feature enables signing of git commits on GitHub. To achieve this, Renovate must be configured with a gitPrivateKey in format supported by openpgp. There must also be a gitAuthor configured to enable this feature.
Closes#897
This PR adds the capability to specify a custom author for git commits on GitHub. Setting this field will mean GitHub uses this value for author and commit instead of the token’s identity. For instance if you are running hosted mode you may set the gitAuthor to “Renovate Bot <bot@renovate.com>” to have commits appear as coming from the renovate-bot account.
