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 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 the capability so that the onboarding commit message (“Add renovate.json”) will have a prefix if semanticCommits is explicitly set to true by the bot administrator.
e.g. “renovate a/b —semantic-commits=true —semantic-commit-type=foo” will result in the onboarding commit being “foobar: add renovate.json”.
Closes#1867
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.
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
If an npm dependency can’t be found, and the package.json has a lock file, then Renovate will encounter lock file errors every time *any* dependency in that package.json has an update. Instead of raising PRs with an error, we instead now stop raising PRs and instead raise a config warning issue. Users can “dismiss” this by setting config option `updateLockFiles` to false.
Closes#1697
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
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.
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 a config option to bot administrators called `exposeEnv`, for cases where repositories are trusted. If set to true, the bot's full `process.env` can be used for `.npmrc` variable substitution and is passed to child processes when generating lock files. Disabled by default, including in the App.
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.
We currently use got’s inbuilt caching for npmjs, however it still results in a roundtrip/304 even when cached. The when using presets is that a package like renovate-config-default gets looked up 10+ times unnecessarily. With this feature we assume that npm lookups don’t change for the duration of a run, and even if they did then we’d prefer the reliability of using the first lookup.
Closes#1389
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
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
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
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 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
Previously, Renovate's "Configure Renovate" onboarding branch would never get rebased after it was created. Now, it will be rebased every time the base branch is updated, unless the list of modified files is more than `renovate.json` alone.
Closes#1111
Remove original getFile, getFileContent, and getFileJson and replace with getFile (which used to be getFileContent.. shortened now for convenience). Also remove unused getSubdirectories functions.
This PR refactors the onboarding PR logic into its own subdirectory and redesigns it to use plain markdown instead of html. Plain markdown in PR bodies is a requirement for adding VSTS Support ( #1049 ).
This refactor means that createPr now takes `labels` as a new parameter so that the GitLab API can include them with the MR creation request, so save one API call. This also fixes#985 as a result.
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
This is instead of autodetecting lib or app during onbiarding. This means some package files might be all pinned while others in the same monorepo can be not. This also simplifies the onboarding logic.
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
This is a failsafe against Renovate bugs and potentially also mistakes on the user’s part. Before deleting/pruning any branches, Renovate will rename the PR’s title so that it should not block future PRs.
Closes#989
* refactor: replace github code search with getTree/manual search (#944)
Previously Renovate was using the GitHub code search API once for each filename we are looking for. Instead, we now retrieve a list of files in the repository and cache it so it can be reused for filename matches.
Closes#939
* fix: use recursive=true
* fix: reset fileList for every repo (github)
* feat: implement findFilePaths on gitlab (#945)
* refactor: do not check manually for root package.json
* fix: reset fileList for every repo (gitlab)
* fix tests
Previously Renovate was using the GitHub code search API once for each filename we are looking for. Instead, we now retrieve a list of files in the repository and cache it so it can be reused for filename matches.
Closes#939
* Revert "feat: support docker and meteor onboarding without npm"
This reverts commit 437145b901.
# Conflicts:
# test/workers/repository/onboarding.spec.js
* chore: downgrade npm cache message from debug to trace
Previously, Renovate assumed that any yarn workspaces configuration would be in the root of the repository. Now, workspaces can be located within a subdirectory, e.g. `frontend/`. Note: Renovate still supports only one workspace per repository, please file an issue if you require more than one.
Closes#842
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
* add minimatch
* feat: use package names for ignoring when lerna or workspaces
Renovate will now:
- Find all package.json files matching lerna or yarn workspaces glob pattern
- Retrieve package names from within those package.json files
- Implicitly ignore (not renvoate) any of those names
Closes#781
If a repository has a lock file error (e.g. can’t look up a private module) then it will no longer attempt to create every branch. Instead, it will error/exit after the first branch. Additionally, “Pin Dependencies” has been sorted to be first and further branches won’t be added or updated until Pin Dependencies has been merged.
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.
Previously, the automerge feature was causing some undesirable behaviour when multiple branches were open at the same time. Example: #707. The main problem is that other branches will still be calculated based on the original `package.json` contents and not the post-merge contents. The simplest solution seems to be:
- Stop all subsequent branch processing after any automerge
- Restart repository renovation
This continues until no branch has automerged in a cycle.
Closes#750
This feature adds explicit support for correctly generating the yarn.lock file for workspaces. Specifically, it means that the yarn.lock in the root directory is regenerated whenever *any* package.json is modified. Previously lock files were only every updated if its corresponding package.json changes, but that is not the way yarn workspaces works.
Closes#473
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.
tmpDir is now created once per-repository and package.json files are written and lockfiles generated based on the repo's directory structure. This way node_modules can be reused between branches in same run.
Closes#501
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
Previously, preset resolution was being done last, after merges of renoate.json or package.json config. This caused wrong ordering of config in cases where both presets + regular config was in use. Instead, resolving of presets is now done at each stage before merging.
Fixes#708
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
Repository initialisation is refactored so that all package files and their content is retrieved up-front before an renovating begins. This allows us to know both how many package files as well as determine if there is renovate json in a package.json before triggering the onboarding PR.
Closes#634
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 feature is particularly useful in the case that renovate is enabled on all repositories a user/account has. Many of those might be forks, and it makes no sense to renovate those by default. Instead, Renovate will skip over forked repositories unless a renovate.json has been added to their root.
Also, Renovate will now prune branches after deciding to skip a repository, whether because of a fork or disablement.
Closes#541
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
If a `lerna.json` is present in the root of the repository, then Renovate will automatically ignore (i.e. not renovate) all package names found in the `packages/*` path. It does not require an explicit configuration to work.
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
Refactored location of branch cleanup so that it can be run even if onboarding is enabled.
This means someone can “undo” a closed Configure Renovate and all other PRs would get cleaned up.
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.
This allows for improvements to renovate’s default renovate.json to be passed on to users who haven’t merged or modified their Configure Renovate PR.
Closes#465
Schedule logic has been refactored to enable the pruning of all orphan branches.
Now, schedules aren't checked at package-time, instead package upgrades are queued regardless of schedule.
At branch time, it is checked whether the *branch* is scheduled and then the branch is not created/updated if it's off-schedule.
This enables the repository worker to know all possible branches and hence be able to determine which remaining branches in the repository are "orphans" to be deleted.
Closes#428, Closes#426
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
A separate routine is run after branch creation to detect any branches that should be deleted. A branch will be removed if:
- It was not created by renovate in the last run, AND
- It has no PR, or its corresponding PR is not mergeable
Closes#426, Closes#428
Warnings and Errors are bubbled up when renovating a repository, together with the existing upgrades. The Onboarding PR ("Configure Renovate") now displays them and encourages the user to fix before merging/closing the PR.
Closes#414
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.
