`target-branch` option for dependabot

[channelbeta]

Code of Conduct

• I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?

https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates

What part(s) of the article would you like to see updated?

The section about target-branch option:

https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#target-branch

By default, Dependabot checks for manifest files on the default branch and raises pull requests for version updates against this branch. Use target-branch to specify a different branch for manifest files and for pull requests. When you use this option, the settings for this package manager will no longer affect any pull requests raised for security updates.

I'm failing to understand that last part (in bold). I've done a quick search on the web and found this question, which also shows a bit of doubt about the meaning of the wording on the docs.

What does it mean? "The settings (which settings?) for this package manager (which package manager?) will no longer affect any pull requests raised for security updates (no longer affect + security updates doesn't sound good to me, am I losing something with this option activated?)".

The expected outcome is a clear explanation of any effects that may arise from using this option.

Additional information

Hi. I've raised the issue as asked by @ramyaparimi in this discussion:

https://github.com/github/docs/discussions/12345

The discussion number though 🤯 1️⃣ 2️⃣ 3️⃣ 4️⃣ 5️⃣

[welcome]

Thanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[ramyaparimi]

@channelbeta
Thanks so much for opening an issue! I'll triage this for the team to take a look 👀

[felicitymay]

Hi @channelbeta - thanks for letting us know that this description is unclear.

All the options in the dependabot.yml file control the behavior of Dependabot version update pull requests. In addition, some of the options also change the default behavior of Dependabot security update pull requests (for example, the assignees field).

Dependabot security update pull requests are always opened against the default branch for the repository. Consequently, when you define an alternative target-branch for a package manager in the dependabot.yml file, the configuration for that package manager is no longer used for Dependabot security updates.

Is that explanation any clearer?

[channelbeta]

Hi @felicitymay , thanks for taking the time to clarify this topic.

Based on your reply, my understanding is:

1. Dependabot has version updates and security updates, and they are not the same thing. I've also re-checked the documentation and they are on different sections version updates vs security updates, so I was wrong in just thinking they were the same thing.
2. By checking the description of the assignees field, I see that it affects both types of pull requests (version updates and security updates), as you said.
3. Except that it will not affect security updates anymore if I set the target-branch option.

So, as an example, suppose that the package manager is Cargo, and my dependency files are inside of /code. I've configured dependabot.yml with:

version: 2
updates:
  - package-ecosystem: "cargo"
    directory: "/code"
    schedule:
      interval: "daily"
    assignees:
      - channelbeta

In the case above, both types of PR will have channelbeta as the assignee, right?

But now, if I change the configuration to:

version: 2
updates:
  - package-ecosystem: "cargo"
    directory: "/code"
    target-branch: "develop"
    schedule:
      interval: "daily"
    assignees:
      - channelbeta

Then version update PRs will be raised to branch develop with assignee channelbeta, while security updates will be raised to the default branch with no assignee (the default behavior). Meaning that, after setting target-branch, security updates will go back to the default behavior for the Cargo package manager. Correct?

If the above is correct, the directory setting (a required option) is still going to be /code for both types of updates, right? There is no "default directory" as far as I know.

[felicitymay]

Hi @channelbeta - thanks for your great illustration. I think that this will help anyone else with questions understand the behavior better ✨

For your examples above, "Meaning that, after setting target-branch, security updates will go back to the default behavior for the Cargo package manager. Correct?" Yes. This is my understanding of how this works.

For the directory setting. My understanding is that it is a required option for version updates, but that it's not needed by security updates. Security updates get information on dependencies from the Dependency graph (which in turn gets them from manifest and lock files) and not from the dependabot.yml file. We're aware that this is confusing and we are planning work to improve both the documentation and the product in this area.

[channelbeta]

Thanks for the confirmation!

I think that this issue can be closed now. Have a nice week 😃

[lucasdavila]

I had the same question.

By what I understood it's possible to change the the target-branch for "version updates" PRs, but its NOT possible to change the target-branch for "security updates" PRs?

Is there any plans to support changing the target-branch for "security updates" PRs as well?

I am asking that because in my case the repositories have a "dev" branch that have more recent code than the "main" branch (and might contain newer versions for the dependencies), plus code merged on "dev" will be tested in a QA env before going to prod (which is related to the "main" branch).

So merging "security updates" PRs directly on main, kind of break the development process, because it was supposed to be merged on dev branch first.

Thanks.

cc @felicitymay