renovatebot_renovate/docs/usage/faq.md

title	description
Frequently Asked Questions (FAQ)	Frequently Asked Questions for Renovate Configuration

Frequently Asked Questions (FAQ)

What is the default behavior?

Renovate will:

• Look for configuration options in a configuration file (e.g. renovate.json) and in each package.json file
• Find and process all package files (e.g. package.json, composer.json, Dockerfile, etc) in each repository
• Use separate branches/PR for each dependency
• Use separate branches for each major version of each dependency
• Pin devDependencies to a single version, rather than use ranges
• Pin dependencies to a single version if it appears not to be a library
• Update yarn.lock or package-lock.json files, if found
• Create Pull Requests immediately after branch creation

Which Renovate versions are officially supported?

Only the latest version of Renovate is supported by the Renovate maintainers. The Renovate team only fixes bugs in an older version if:

• the Mend Renovate App needs to stay on that older major version for a short time, or
• some critical bug needs to be fixed and the new major is blocked

If you're using the Mend Renovate App, you don't need to do anything, as the Renovate maintainers update it regularly. If you're self hosting Renovate, use the latest release if possible.

When is the Mend Renovate App updated with new Renovate versions?

The Renovate maintainers manually update the app. The maintainers don't follow any release schedule or release cadence. This means the Mend Renovate App can lag a few hours to a week behind the open source version. Major releases of Renovate are held back until the maintainers are reasonably certain it works for most users.

How can I see which version the Mend Renovate app is using?

Follow these steps to see which version the Mend Renovate app is on:

1. Go to the Mend Developer Portal

2. Sign in to the Renovate app with your GitHub or Bitbucket account

3. Select your organization

4. Select a installed repository

5. Select a job from the Recent jobs overview

6. Select the Info Log Level from the dropdown menu

7. You should see something like this:

   INFO: Repository started
   {
     "renovateVersion": "38.120.1"
   }
   

!!! tip The PRs that Renovate creates have a link to the "repository job log" in the footer of the PR body text.

Renovate core features not supported on all platforms

Feature	Platforms which lack feature	See Renovate issue(s)
Dependency Dashboard	Azure, Bitbucket, Bitbucket Server, Gerrit	#9592
The Mend Renovate App	Azure, Bitbucket Server, Forgejo, Gitea, GitLab

Major platform features not supported by Renovate

Some major platform features are not supported at all by Renovate.

Feature name	Platform	See Renovate issue(s)
Jira issues	Bitbucket	#20568
Jira issues	Bitbucket Server	#3796
Merge trains	GitLab	#5573
Configurable merge strategy and message	Only Bitbucket, Forgejo and Gitea for now	#10867 #10869 #10870

What is this main branch I see in the documentation?

When you create a new repository with Git, Git creates a base branch for you. The default branch name that Git uses is master (this will be changed to main later).

The Git-hosting ecosystem decided to use main instead of master. When you create a new repository on say GitHub or GitLab, you'll get a main branch as your base branch.

We replaced master with main in our documentation where possible.

A branch name has no special meaning within the Git program, it's only a name. The base branch could be called trunk or mainline or prod, and Git would work just as well.

What if I need to .. ?

Troubleshoot Renovate

If you have problems with Renovate, or want to know where Renovate keeps the logging output then read our troubleshooting documentation.

Tell Renovate to ask for approval before creating a Pull Request

By default, Renovate creates a pull request right away whenever there's an update. But maybe you want Renovate to ask for your approval before it creates a pull request. Use the "Dependency Dashboard approval" workflow to get updates for certain packages - or certain types of updates - only after you give approval via the Dependency Dashboard.

The basic idea is that you create a new packageRules entry and describe what kind of package, or type of updates you want to approve beforehand.

{
  "packageRules": [
    {
      "matchUpdateTypes": ["major"],
      "matchManagers": ["npm"],
      "dependencyDashboardApproval": true
    }
  ]
}

{
  "packageRules": [
    {
      "matchPackageNames": ["jest"],
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true
    }
  ]
}

You may even configure Renovate bot to ask for approval for all updates. The dependencyDashboardApproval config option is outside of a packageRules array, and so applies to all updates:

{
  "dependencyDashboardApproval": true
}

Read our documentation on the dependencyDashboardApproval config option.

Use an alternative branch as my Pull Request target

Say your repository's default branch is main but you want Renovate to use the next branch as its PR target. You can configure the PR target branch via the baseBranches option.

Add this line to the renovate.json file that's in the default branch (main in this example).

{
  "baseBranches": ["next"]
}

You can set more than one PR target branch in the baseBranches array.

Support private npm modules

See the dedicated Private npm module support page.

Control Renovate's schedule

To learn about controlling Renovate schedule, read the key concepts, scheduling docs.

Disable Renovate for certain dependency types

Define a packageRules entry which has the dependency type(s) in matchDepTypes and "enabled": false.

Use a single branch/PR for all dependency upgrades

Add a configuration for configuration option groupName set to value "all", at the top level of your renovate.json or package.json.

Use separate branches per dependency, but not one per major release

Set configuration option separateMajorMinor to false.

Keep using SemVer ranges, instead of pinning dependencies

Set configuration option rangeStrategy to "replace".

Keep lock files (including sub-dependencies) up-to-date, even when package.json hasn't changed

By default, if you enable lock-file maintenance, Renovate will update the lockfile ["before 4am on monday"]. If you want to update the lock file more often, set the schedule field inside the lockFileMaintenance object.

Wait until tests have passed before creating the PR

Set the configuration option prCreation to "status-success". Branches with failing tests will remain in Git and get updated if needed. Renovate will only create a PR once the tests pass.

Wait until tests have passed before creating a PR, but create the PR even if they fail

Set the configuration option prCreation to "not-pending".

Assign PRs to specific user(s)

Set the configuration option assignees to an array of usernames.

Add labels to PRs

Set the configuration option labels to an array of labels to use.

Apply a rule, but only to package abc?

1. Add a packageRules array to your configuration
2. Create one object inside this array
3. Set field matchPackageNames to value ["abc"]
4. Add the configuration option to the same object

e.g.

{
  "packageRules": [
    {
      "matchPackageNames": ["abc"],
      "assignees": ["importantreviewer"]
    }
  ]
}

Apply a rule, but only for packages starting with abc

Do the same as above, but instead of an exact match, use a glob prefix:

{
  "packageRules": [
    {
      "matchPackageNames": "abc**",
      "assignees": ["importantreviewer"]
    }
  ]
}

For more examples, see String Pattern Matching, example glob patterns.

Group all packages starting with abc together in one PR

As above, but apply a groupName:

{
  "packageRules": [
    {
      "matchPackageNames": "abc**",
      "groupName": ["abc packages"]
    }
  ]
}

Change the default values for branch name, commit message, PR title or PR description

You can use the branchName, commitMessage, prTitle or prBody configuration options to change the defaults for those settings.

Automatically merge passing Pull Requests

Set the configuration option automerge to true. Nest it inside a patch or minor object if you only want to automerge certain types of updates.

Separate patch releases from minor releases

Renovate's default behavior for major/minor releases

By default, Renovate separates major and minor releases. Patch releases are treated as "minor". Here's an example:

Say you're using version 0.8.0 of the foo package. The foo maintainers release the following versions:

• 0.8.1 (patch)
• 0.9.0 (minor)
• 1.0.0 (major)

Renovate creates the following PRs:

• Update dependency foo to 0.9.0 (minor)
• Update dependency foo to 1.0.0 (major)

Renovate groups the patch and minor versions into one PR. This means you only get a PR for the minor version, 0.9.0.

You can override this default behavior. To learn more read the section below.

Overriding the default behavior for major/minor releases

You can see in the example above that Renovate won't normally create a PR for the foo patch release.

You can tell Renovate to create a separate PR for the patch release by setting separateMinorPatch to true.

In both cases, Renovate will open 3 PRs:

• Update dependency foo to 0.8.1 (patch)
• Update dependency foo to 0.9.0 (minor)
• Update dependency foo to 1.0.0 (major)

Usually you don't want more PRs though. It can be nice to get patch PRs when you're using automerge:

• Get daily patch updates which are automerged once tests pass
• Get weekly updates for minor and major updates

This means you barely notice Renovate during the week, while you still get the benefits of patch level updates.