renovatebot / renovate

Universal dependency automation tool.

Renovate

Automated dependency updates. Multi-platform and multi-language.

Why Use Renovate?

• Get automated Pull Requests to update your dependencies
• Reduce noise by running Renovate on a schedule, for example:
  • on weekends
  • outside of working hours
  • each week
  • each month
• Relevant package files are discovered automatically
• Supports monorepo architectures with workspaces with no extra configuration
• Bot behavior is customizable via configuration files (config as code)
• Use ESLint-like shared config presets for ease of use and simplifying configuration (JSON format only)
• Lock files are supported and updated in the same commit, including immediately resolving conflicts whenever PRs are merged
• Get replacement PRs to migrate from a deprecated dependency to the community suggested replacement, works with most managers, see issue 14149 for exceptions
• Open source (installable via npm/Yarn or Docker Hub) so can be self-hosted or used via the Mend Renovate App

Supported Platforms

Renovate works on these platforms:

• GitHub (.com and Enterprise Server)
• GitLab (.com and CE/EE)
• Bitbucket Cloud
• Bitbucket Server
• Azure DevOps
• AWS CodeCommit
• Gitea and Forgejo
• Gerrit (experimental)

Who Uses Renovate?

Renovate is widely used in the developer community:

Renovate OSS Insights

Renovate is built on a big community and actively invites and supports contributions. Information about our contributors and community can be found on OSS Insight.

Star History

The Renovate Approach

We believe everyone benefits from automation, whether it's a little or a lot. This means that Renovate:

• Adapts to your workflow
• Allows you to configure its behavior
• Will autodetect settings where possible

Using Renovate

Get started with Renovate by checking out our tutorial.

GitHub

We recommend that you use the Mend Renovate App. Install the Mend Renovate App now. More details on the Mend Renovate App installation.

Azure DevOps

There are two ways to run Renovate on Azure DevOps:

• Renovate Me extension
• Custom pipeline

Renovate Me extension

Go to the Visual Studio Marketplace and install the Renovate Me extension in your organization. From there you can create a pipeline with the RenovateMe task.

Note

This extension is created and maintained personally by a Renovate developer/user so support requests relating to the extension itself cannot be answered directly in the main Renovate repository.

Custom pipeline

You can create a custom pipeline with a yml definition that triggers npx renovate. More details on how to configure the pipeline.

Bitbucket Cloud/Server, Forgejo, Gitea, GitLab

For Bitbucket Cloud, Bitbucket Server, Forgejo, Gitea and GitLab, use our self-hosting option.

Configuration

Go to our documentation website to learn how to configure Renovate. We have a full list of configuration options.

To get help with your configuration, go to the discussions tab in the Renovate repository and open a new "config help" discussion post.

Self-Hosting

To run your own instance of Renovate you have several options:

• Install the renovate CLI tool from npmjs, run it on a schedule (e.g. using cron)
• Run the renovate/renovate:full Docker Hub image (same content/versions as the CLI tool), run it on a schedule
• Run the renovate/renovate:latest Docker Hub image if you only use package managers that don't need third-party binaries (e.g. JavaScript, Docker, NuGet, pip)

More details on the self-hosting development.

Contributing

If you want to contribute to Renovate or get a local copy running, please read the instructions in contributing guidelines. To get started look at the list of good first issues.

Security / Disclosure

If you find any bug with Renovate that may be a security problem, then e-mail us at: [email protected]. This way we can evaluate the bug and hopefully fix it before it gets abused. Please give us enough time to investigate the bug before you report it anywhere else.

Please do not create GitHub issues for security-related doubts or problems.

renovate's Issues

Support interactive mode

CLI --interactive

Allow the user to accept or skip each dependency. If they skip a dependency, give them the option to permanently ignore it.

CI

First lint, later tests

Support modifying unmergeable branch/PR instead of recreating

I don't know if this is technically possible, but it would be great if we could update/modify "unmergeable" PRs instead of closing them and creating a new one.

Add stronger checks for existing versions

This happened to me by accident:

And although it was a welcome upgrade, I'm not sure it should be done by default.

Force

Clean = remove all created pull requests?
Force = create PRs even if they existed before?

Anything else to be considered?

For closing PRs and deleting branches, should we be worried if someone has used a "real" account for renovate and it closes their real/human PRs? I think let's assume they shouldn't do that, and if they do then they need to be aware of the consequences of renovate --clean. Also, they can reopen a PR and restore a branch through GitHub's web interface.

Yarn support

Hello,

It would be really awesome to support yarn and update the yarn.lock in each PR.

I don't know if this is doable with a javascript api or if this is in the scope of renovate (maybe this should be done by another bot/binary).

lint

Add tests

Document configuration

Support "enabled" flag

Consider using logger

Add Changelogs

Add Changelogs and/or links to change logs to the PR description

Support single branch/PR for all dependencies

Current behaviour (non-configurable) is one branch/PR per dependency.

Skip git altogether

Is it possible to do all the git options via the GitHub API instead?

• Get the master package.json: https://developer.github.com/v3/repos/contents/#get-contents
• This could also be used to check if an upgrade branch already exists for a package, and get that branch's package.json too.
• Get master SHA: https://www.quora.com/How-can-I-retrieve-the-hash-of-the-latest-commit-to-a-GitHub-repository-through-GitHub%E2%80%99s-API
• Create a new branch off master SHA: https://gist.github.com/potherca/3964930
• Update a file (i.e. in new branch): https://developer.github.com/v3/repos/contents/#update-a-file

Branch naming

Currently we name like upgrade/angular and upgrade/angular-major, where angular is an example package name. Is this OK?

Support cascading configuration

For topics such as #29, it would be useful if our configurations were cascading. e.g. ignoring peerDependencies could be configured on a global, repo, or package file basis. For most configuration options it wouldn't make sense to have them configured so granularly, however it probably doesn't hurt to support the concept for all.

Publish to npm

Should we support global install so you can just run renovate ?

Support peerDependencies and optionalDependencies

Currently we only check dependencies and devDependencies. Under what circumstances would we want to update peer and optional dependencies too?

Support renovate.json file in repo

As an alternative to embedded package.json configuration

Support npm shrinkwrap

Similar to #66

Support persisting ranges

Currently we always pin dependencies. Is there a reason why people would want to keep ranges in their updates, and how would this be decided and configured?

e.g. let's say they currently have ~1.1.0 and there exists versions 1.2.0, 1.3.0, 2.0.0 and 2.1.0. What PR would you raise?

Support Custom Registries

Many corporate environments have their own internal npm registries (using platforms like Artifactory).

In some cases, public packages can only be fetched from these internal registries.

Furthermore, many companies host their own private scoped packages on a separate registry than their cache of the public registry.

Therefore, hard-coding the npm registry would hinder the use of renovate in corporate, or otherwise, locked down environments.

registry-url is a convenient tool for fetching the registry URL associated with a package. An example of its use can be seen in package-json.

Clean

Option to clean up all branches/PRs created by the renovate account?

Update stale PRs

By "stale" I mean PRs that are no longer up-to-date with the base branch. This would happen every time someone makes a commit to master, for example - so I'm not sure if many people at all would want so many automated tests to be enqueued (e.g. 5 open renovations and 10 commits to master per day would result in 50 extra pull requests).

Probably best to wait for #52 first, at least.

Fix failure to create PR

From renovating this repository:

2017-01-28T07:10:55.534482+00:00 app[scheduler.8465]: info: Processing singapore/renovate package.json
2017-01-28T07:10:57.516131+00:00 app[scheduler.8465]: error: clear-require failed to ensure PR: HTTPError: Response code 422 (Unprocessable Entity)
2017-01-28T07:10:57.516487+00:00 app[scheduler.8465]: info: singapore/renovate package.json done

When I ran the CLI command manually after that, the PR was created.

Add Pull Request description

Expand on PR title to describe which dependency is being upgraded from.

Gitlab support

This seems very useful. Would it work with gitlab instead of github? If not, any plans to support that?

Committer name/email

Which name/email should be used for git commits?

• Hardcoded "renovate bot"?
• Configurable/overrideable setting?
• auto-retrieved somehow via GitHub API?

Although commercial services like Greenskeeper and Doppins "own" their commits, doing so in an open source tool like this would feel sleazy, unless it's only as a helpful default that's easily overridden.

I think - to avoid confusion - ideally it should be the same identity that:

• Authors git commits
• Pushes or updates branches to GitHub
• Raises Pull Requests

To avoid requiring configuration of the name/email for git, does the GitHub API support a "who am I?" type of query?

Improve major/minor upgrade logic

Currently we just look at the "latest" tag from npm. This should be improved/replaced by instead looking for both the latest minor or patch upgrade as well as major upgrade for each package, by checking the dependency's versions list.

Support configuration via repository package.json

Support allowing a renovate configuration per-package.json

Support PR labels

Deploy to Heroku button

Heroku button: https://devcenter.heroku.com/articles/heroku-button
app.json: https://devcenter.heroku.com/articles/app-json-schema
Scheduler: https://devcenter.heroku.com/articles/scheduler
Custom clock processes: https://devcenter.heroku.com/articles/scheduled-jobs-custom-clock-processes#custom-clock-processes

Refactor/split code into multiple files

Support range grammar

So far it's been assumed/tested that existing package.json dependencies use pinned versions, such as 1.6.0 and not such as ~1.6. So for now, this is an undocumented prerequisite of the tool. Ideally we could handle initialising a repo with non-pinned versions and pinning them.

Avoid excess builds

Renovate's current approach is to use the API and then in this order:

1. Create branch
2. Add upgrade commit
3. Create Pull Request

One observed problem is that CI systems such as CircleCI are building after both steps 1 & 2:

The first build (bottom one) is unnecessary and a waste of a build cycle, as it's just an empty branch off master.

Unfortunately, I'm not sure if it's possible to combine branch creation + file updating into one transaction when using the API.

Make verbose a CLI argument

Flexible configuration inputs

We have a number of configurations required for this script, such as:

• GitHub token to be used
• Repository (or repositories?)
• Package.json location(s)
• Customisations (e.g. branch prefixes)

We need a way of flexibly configuring these for most commonly used environments, which should also include "headless" ones like cron jobs on servers or AWS lambda.

Ignore "future" releases

npm supports the tag "future" for versions. This seems to be akin to "unstable" but I'm not sure if this is the same thing. e.g. perhaps releases like "1.0.2-rc0" are not marked as future while releases like "2.0.3" are marked as future.

Support dependency groups

e.g. upgrade angular and core angular dependencies (e.g. angular-touch) together.

Unstable release upgrades

Default behaviour should definitely be that we don't update from stable to unstable. Any project wishing to try an unstable package release should do that manually.

However, if a project is already using an unstable release, they would presumably want access to upgrades, such as from release candidate 1 to release candidate 2 or from a release candidate to final release.

Hence it is a nice-to-have feature that any existing unstable versions are checked for possible upgrades.

Don't reformat package.json

If we read the entire package.json file in, then update it using javascript, and then export/save it - then the first time might end up with huge changes to the existing package.json file. Could we instead apply a "surgical" regular expression replacement, once we've decided what to replace?

Recreate unmergeable Pull Requests

If real users have updated a renovate branch, then it wouldn't be a good idea to close or delete the existing branch. But let's say a PR is out of date or- worse still - conflicted with the base branch, as often happens when updating adjacent dependencies. In such scenarios, would people prefer that we delete the old PR and create a new one? I don't think that rebasing the branch is possible via API, let alone in a non-interactive way. It might be possible to do the equivalent of a "force push" for a branch though.

Selective template override

Currently if you override templates, you need to override all of them. It would be nice if you could override selectively - including at multiple levels - and then have the app "fill in the blanks".

Support dependency ignoring

This sounds like it would be on a per-repo basis but maybe also global.

Support assignees

Exit if no renovate token

Also check for appropriate error if token is invalid

Automatic deploy (GitHub/Heroku)

Both GitHub and Heroku support OAuth. In theory it would be possible to generate an auth token in GitHub and create an app on Heroku all within the browser, and then "forget" the credentials.

Would people be willing to "risk" some security by temporarily granting these permissions, to save the time setting it up?

Any other platforms (e.g. AWS lambda) that this would also be possible for?

SSH key pair

We use an SSH key pair to support git operations. Here are some ways this can be done:

1. Manually add public key (where script will run) to GitHub account (e.g. id_rsa.pub)
2. Generate dedicated keypair for this script and add that manually to GitHub
3. Script generates SSH keypair and adds it to GitHub using API - if not already present due to previous run

Deploy to AWS (lambda)

Like LambCI is doing: https://github.com/lambci/lambci

Discover package.json files

It seems possible to "search" a repository for package.json files using the API: https://developer.github.com/v3/search/#search-code

I guess we could discover and renovate all package.json files per repository unless the user configures package.json manually?