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
This PR adds new checks that:
- Website configuration options are listed in alphabetical order
- Every relevant configuration option in source code is documented on the website
Website docs have been updated accordingly to pass.
Closes#543, Closes#1310
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 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.
This PR adds support for bazel WORKSPACE package files, as suggested https://github.com/alexeagle/angular-bazel-example/issues/17#issuecomment-349167982
Renovate will:
1. Detect `WORKSPACE` files anywhere in the repository
2. Look for all `git_repository()` sections in the file
3. Extract any dependencies with name, remote and tag values
4. Look up any dependencies that (a) have a github https remote, and (b) a valid semver as tag
5. Update the tag to the latest available
This PR adds support for renovating the `node_js` versions in `.travis.yml` configuration files. Important notes:
- Functionality is disabled by default and hence opt-in via configuration
- Added a new manager type `node` because it is anticipated to support more than just Travis in future, with mostly unified logic
- Added the config option "policy" with supported values: lts, active, current, lts_latest and lts_active
- Policy is actually an array, to allow additive combining, e.g. `["lts_latest", "current"]`
- Actual node versions are *hardcoded*. There is no perfect metadata source for this and they change infrequently enough that it is definitely not a problem for now (next change will be in April 2018)
- If node versions need updating, they are listed from newest to oldest
- Replacing function attempts to detect the indention (spacing) in file and use that
To enable, configure `node.enabled=true` and optionally `node.policy=["<policy>"]` if you want something other than `lts`.
Closes#1208
If we have in a package.json links to some local lib file:../path/to/folder
Then the local lib package.json will be copied to the tmp folder to be able to generate the right yarn lock file. This is not working with tgz files, only folder reference.
Closes#1215
