Dependabot for stable release branches

[asklar]

With more emphasis on longer-term servicing branches, it would be important to keep N & N-1 updated re: dependabot. As far as I can tell, dependabot isn't configured in any special way in our repo so only master is kept updated

[NickGerleman]

An important distinction here is that generally, dependabot changes don't affect users of RNW, since it usually just updates our lockfile based on allowed semver ranges in package.json. Consumers will just have these ranges, without our lockfile.

Security specific updates might be a different matter though.

[chrisglein]

We should take a look at whether something needs to happen here. We want to know when we have a dependency that has a critical fix since we published. Not sure what combination of Dependabot and Governance management is involved here. We don't want to wait until our next patch release to find any Governance issues. We may want a trial run of publish regularly to find these?

[chrisglein]

Danny van Velzen (@dannyvv) Do you have any ideas on what's the right way to catch these issues?

[NickGerleman]

You can tell dependabot to look at a target branch, and supply multiple configurations. See https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#target-branch

[jonthysell]

Unfortunately using target-branch would open dependabot PRs for all version updates in stable branches, when all we really want are automatic security updates. And that feature has been blocked for years at this point: dependabot/dependabot-core#2767

The closest workaround is to set open-pull-requests-limit: 0 for a config so only security updates get opened, but that only works on the default branch since the security scanner itself only looks at the default branch.

So as of today there's no way to "mix" the target-branch and open-pull-requests-limit fields to get what we want.