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 reverts commit 4f65356ba4.
I will attempt to merge npmrc configs a different way, as npm itself does not support merging cascaded configs (it finds the most specific one and just uses it).
Rename writeToken to forkToken to make it clearer. This enables GitHub API to use one token for all reads, and another token just for writing to the forked repository.
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
With this PR, Renovate will default to raising only one major PR at a time. e.g. if you have Webpack 1.x then you will get only one major PR for webpack v3 and not also for v2. set multipleMajorPrs=true to get multiple.
Closes#1101
This adds a configuration option unstablePattern - used only by Docker currently - that can be used to define a regex patternt to identify “unstable” versions.
Closes#1035
99% of the time we should not Renovate forked repositories. Previously, we skipped onboarding them unless a renovate.json was present. However, that meant that if someone forked a repository where the source was using Renovate, then the fork gets renovated automatically too. After this change, forked repositories need to set renovateFork=true in their renovate.json
Closes#940
BREAKING CHANGE: Forked repositories now need to configure renovateFork=true in renovate.json
Renovate will now check ignorePaths values for either (a) a string match, or (b) glob pattern. e.g. a string of ‘node_modules/‘ will ignore ‘node_modules/foo/package.json’ and ‘backend/node_modules/foo/package.json’ but it will also ignore ‘not_node_modules/foo/package.json` too. Therefore a blog pattern of `**/node_modules/**` is superior.
Closes#1054
BREAKING CHANGE: ignorePaths now supports globs and may match more than before, but that’s probably a good thing.
By defaulting pinVersions to null, this allows Renover to autodetect on a per-package file basis. Users may still manually configure (override autodetection) pinning enabled or disabled via config.
Closes#589
BREAKING CHANGE: Renovate will no longer default to pinning versions - instead it will autodetect whether to pin, unless overrided.
This feature enables docker tag "upgrading". Examples:
- From `node:6` to `node:8`
- From `node:6.10` to `node:6.11`
- From `node:6.11.1` to `node:6.11.3`
- From `node:6.10-onbuild` to `node:6.11-onbuild`
Currently these are disabled by default so they are opt-in, you can enable them by setting e.g. `{ docker: { minor: { enabled: true }, major: { enabled: true }}`
Closes#930
This commonly applies to monorepos where the same dependency may be present in multiple.json files. Instead of using the group name to describe the PR, it uses the dependency name.
Closes#848
By default, Renovate will now continue *updating* - but not creating - branches even if off-schedule. This applies to features such as (a) rebasing branches if master changes, (b) updating if new version comes, (c) creating PRs if tests pass, (d) automerging. It is planned that (b) will be configurable in a future feature. To disable this behaviour altogether, set updateNotScheduled to false.
Closes#879
Setting lockFileMaintenance.groupName = null will prevent the case where the user configures a repository groupName like “all” and then that group inherits the schedule of lock file maintenance. Instead, there will be renovate/all and renovate/lock-file-maintenance.
Fixes#885
This feature adds initial support for renovating Dockerfiles. Renovate now:
- Detects all `Dockerfile`s in repo
- Searches for `FROM x` in first non-comment line, breaks x into image, tag, digest
- Queries public Docker registry for image:tag combination to find latest digest
- Patches Dockerfile if necessary
- Creates branches/PRs as like with npm
Closes#795
This feature adds support for renovating Meteor's `package.js` files. Meteor config is disabled by default so must be manually enabled to work. If enabled, Renovate uses GitHub's search API to look for any files named `package.js` that include the text `Npm.depends`. If so then the file is parsed using Regex to extract its dependencies and check them for updates.
Closes#785
* fix: migrate “every xday” to “on xday”
* fix: do not migrate before and after if before is after after
e.g. do not migrate “after 1am and before 5am”
A new config object `encrypted` can be defined at any level and contain encrypted configuration strings. Initial use is for encrypting an npm token for use with the hosted renovate app.
Closes#650
Renovate config can now support the fields `npmToken`, `npmrc` and `yarnrc`. `npmrc` and `yarnrc` (note no `.` prefix) can be used as an alternative to checking the respective files into the repo and have the same effect. `npmToken` is a shorter alternative and allows for just the npm token to be added, defaulting to the public npm registry.
We should not leave the PR unopened forever if the branch remains in not-pending state too long. Some status checks may leave the status as “pending” instead of “failed”. Defaults to 12 hours but is configurable.
Closes#747
The ignoreNodeModules feature is replaced with a generic ignorePaths one and allows any array of strings to be defined and package.json file matching them will be skipped/ignored. Also migrates any existing config/presets.
This is a major refactor of branch code to prepare for Yarn workspaces plus creating PRs for branches with failing lockfiles. Marked as "feature" to cause a minor version bump due to the moderate chance of accidentally breaking something.
This makes for an uglier migration and potentially some redundancy, but is the only easy way to ensure that the migrated behaviour is definitely correct.
Fixes#713
Refactored the `automerge` field to change it to boolean. Existing string will be migrated to new config. Automerging lock files is now possible by adding `”lockFileMaintenance”: { ”automerge”: true}` to config.
Closes#706
This PR implements eslint-inspired shareable configs. With this feature, we:
- Add new config option "extends"
* This is an array of preset config names that the current config or preset extends/inherits from
- Add new config option "description"
* Each preset config should include a description of its functionality that is human-readable
- Provide a set of commonly use configs called "preset defaults"
- Provide two "full" preset configs: "app" and "library"
* Almost the same but app pins *all* version numbers while library only pins devdependencies
- Replace regular config in onboarding with one of these two presets
- Generate human-readable description of config in Onboarding PR
- Support npm for hosting configs (both scoped and non-scoped)
Closes#657, Closes#671, Closes#647
It was a mistake to enable this feature by default, and should be disabled. A check has been made to set the status to “success” if it was previously “pending” and the setting is now false. This should also cover the case when someone enables it and then disables it.
Fixes#667
Renovate now adds a status check renovate/unpublish-safe that has the following behaviour:
If any upgrade in the branch is < 24 hours old then the status check state is "pending"
If all upgrades in the branch are 24 hours or more old then the status check state is "success"
This is able to be disabled via a new option "unpublishSafe".
Closes#494
No need for {{semanticPrefix}} to be specified in templates now - it will be implicitly added to start of commit message and PR titles if semanticCommits=true
depTypes configuration is now refactored from being an array of strings/objects to having each type of dep (`dependencies`, `devDependencies`, `optionalDependencies`, `peerDependencies`) be a first class object in the namespace. The "old" way of configuring is still supported but is transformed using a migrateConfig script. Later, PRs will be raised to impacted repositories to suggest the new config.
This PR adds explicit patch support. A user can set `separatePatchReleases` to true and receive not only major/minor updates but also patch updates separately. This functionality is also implicitly enabled if `automerge` is set to `patch`.
This PR also enables separate major/minor/patch configuration, e.g. config overrides for major versions, for patch versions, etc. `branchName` is currently overridden for patch branches using this technique.
Closes#390, Closes#538
GitHub attempts to autolink any @user mention and this causes problems when we use scoped npm modules like `@types/gulp`. This escapes such package names with a zero width space to fool GitHub’s parser.
Fixes#518
This PR adds detection and log warnings for the following config validation errors:
- Unknown config option (e.g misspelling of a valid config option)
- Config option is a wrong type (e.g. string instead of boolean)
It does *not* propagate this warning to the user (i.e. in onboarding or PRs) yet due to the high chance that we'll find a false negative. I will watch logs for a week or so and then once happy with results will activate user-visible warnings via #556.
Closes#548, Closes#555
This removes the need to JSON.stringify() objects in logs. Default bunyan fields plus our custom meta fields are stripped out, and everything else is stringified in the details field.
Closes#498
Previously, when someone declared a repository groupName such as “All”, it resulted in lock file maintenance updates being grouped together as well. This is undesirable, especially if the All group then inherits the lock file maintenance schedule.
Fixes#483
Renovate will now ignore any package.json files found within node_modules folders, with the option to disable this functionality by setting config.ignoreNodeModules=false.
Collaborator
rarkins commented 14 hours ago
Base branch for Pull Requests is now configurable via a new baseBranch configuration option. To take effect, this much be present in the default branch (e.g. master in most cases) so that it can be discovered and used. See FAQ for more details.
Closes#443
This starts off [#359](https://github.com/singapore/renovate/issues/359) (configurable status checks) but only implements one sub-feature of it: disabling status checks to allow automerge if tests fail or if no tests are present.
This changes how group are configured to align with the new lock file configuration.
BREAKING CHANGE: old group* template options are no longer supported but can be migrated into group object
This feature now allows a custom schedule to be defined for lock file maintenance. It is now enabled by default but runs only before 5m on Sundays. Closes#399
BREAKING CHANGE: lock file maintenance is enabled by default.
Rules will apply to both yarn and npm (npm is yet to be implemented however). Existing mainainYarn* variables are removed and replaced by new lockFileMaintenance object.
This PR adds a scheduling feature, including timezone support.
It's described in detail in the FAQ, but the summary is:
* Timezones can be defined so that schedules are written in timezone of target repository
* Schedules can be written in "plain english"
* Multiple schedules allowed
* Schedules can be defined all the way down to package level
Closes#387
Add support for automerging without PR, Closes#177
* update definitions and docs
* Add mergeBranch api
* support merge commit
* set automergeType
* Update API
* Refactor merge commit
* branch-push working
* Refactor branch
* Add back base tree
* Fix failing tests
* Update definitions and docs
* Fix automerge logic
* Test isBranchStale
* start mergeBranch test
* test mergeBranch branch-push throws
* more tests
* test unknown commit type
* pr tests
* Detect automerge in versions helper
* update tests for new automergeEnabled flag
* refactor pr logic
* complete pr worker tests
* branch automerge tests
* Update docs
* refactor branch automerge check
