Combined dependencies PR

[rnorth]

Combining multiple dependencies PRs into one:

• Bump junit-jupiter-engine from 5.7.1 to 5.7.2 in /modules/junit-jupiter (Bump junit-jupiter-engine from 5.7.1 to 5.7.2 in /modules/junit-jupiter #4117) @dependabot
• Bump tomcat-jdbc from 10.0.0 to 10.0.6 in /modules/jdbc (Bump tomcat-jdbc from 10.0.0 to 10.0.6 in /modules/jdbc #4085) @dependabot
• Bump assertj-core from 3.18.1 to 3.19.0 in /modules/database-commons (Bump assertj-core from 3.18.1 to 3.19.0 in /modules/database-commons #3721) @dependabot

[rnorth]

This PR was created using a simple bash script that iterates over open dependencies PRs. I'll share the script later.

I've made it add closes: entries to the body for PRs that are being combined. I wonder if it would be worth experimenting to determine if there's a better approach - I'm thinking about how release-drafter will react. Perhaps not closing the original PR, but letting GitHub detect that the original PR should be marked merged by virtue of its head commit being merged into master. I'll experiment with this aspect in a separate repo, as it's not something that can be easily reversed if it fails to work.

There seems to be something screwy with GitHub's PR search as well: I'm using gh pr list --search "label:dependencies status:success" which I believe should list all dependencies PRs that are passing checks. I'm only getting three results back right now, though, which is fewer than it should be. 🤔

[rnorth]

Good news, having tested a few things over in https://github.com/rnorth/pr-closure-test:

• GitHub detects closure of the original PR when its commits are merged in the combined PR. Therefore, it's not necessary to put closes #XYZ in the combined PR. We can put something like Includes #XYZ for reference.

• Release Drafter also behaves as we'd want: the original PRs are included in the draft release. We actually see (a) each of the original PRs, and (b) the combined dependencies PR, as shown here: https://github.com/rnorth/pr-closure-test/releases/tag/0.0.1 (only using one original PR here)

[rnorth]

Double-checking the above observations in this repo.

[rnorth]

Welp, it doesn't seem to have worked here. Looking into why.

[rnorth]

Ah I know now: This approach does not work if 'squash and merge' is used, which is entirely reasonable. We don't currently have 'Allow merge commits' enabled in this repo.

I think the benefits will outweigh the costs of enabling this merge type. Will raise a separate issue to track this work.