Add extra notes that detail how we use Dependabot

[benthorner]

Previously we had regular discussion on GOV.UK about how we can
make Dependabot less burdensome. This adds and consolidates the
notes on Dependabot to record the outcome of those discussions,
so we don't keep having them again, and again, and...

This PR was at one point a discussion area for a potential change for
an account setting. However, we decided to leave it as-is, and instead
add a note to explain why.

At the time of raising this PR, the note about the setting to "Treat PR
approval as a request to merge" is still under discussion. This PR is also
serves as a place to continue that discussion. Some useful facts about
this setting, from previous discussions:

• Will the commits be signed? Yup, by GitHub. So that shouldn’t break any pipelines that only permit commits from specific entities.
• Will the commit message be the same? Yup, so this shouldn’t break any pipelines that are parsing the commit messages.

[benthorner]

Comment from @36degrees

On the Design System team, we’ve restricted it so that only members of the team can push to the master branch. This is so that we can grant write access to all frontend devs at GDS (so that their PR approvals ’count') but two FE devs couldn’t ship a change without our team being involved.

I’d be keen to check that Dependabot doesn’t trip up on this, as in theory it shouldn’t be able to merge to master, but it may try anyway!

Other than that, sounds sane to me.

My understanding is that this setting should be compatible with that way of working: Dependabot has write access to the repo, but not the required admin or maintainer that you've got protecting the master branch. Note: most of our repos don't have this protection.

[heathd]

it would be good to know specifically what configuration settings you propose to use.

also if you can link to the official documentation of what each option does

the "enable auto-merging to be enabled on projects" sounds as though it can be enabled on a per-project basis?

[benthorner]

@heathd this PR makes a few tweaks to the notes to clarify the guidance we already have. The only actual change proposed is to enable: "Treat PR approval as a request to PR".

Although we've checked "Allow auto-merging to be enabled on projects" for individual repos, this conflicts with the guidance about requiring at least one approving review.

I've been unable to find any documentation about this feature, apart from informal discussion that it's equivalent to @dependabot merge, and that it can only be enabled org-wide.

[richardTowers]

Could add GOV.UK PaaS to this too - dependabot's used for the nodeJS frontend.

[heathd]

ah ok, so the "Allow auto-merging to be enabled on projects" is a different behaviour to the "Treat PR approval as a request to PR" function?

If I understand correctly:

1. Allow auto-merging to be enabled on projects would allow a project to enable auto-merging. Auto-merging is where a PR gets merged even if it doesn't have approval from a reviewer?
2. Treat PR approval as a request to PR means that once a PR has been approved it gets merged

did I understand correctly?