Here is an example https://github.com/pavelfomin/spring-boot-rest-example/pull/42/changes. It uses this simple shared workflow https://github.com/pavelfomin/shared-workflows/blob/main/.github/workflows/dependabot-automerge.yml.
Here is the auto merged dependabot PR: pavelfomin/spring-boot-rest-example#52
And you can see some other dependabot PRs created but not merged because of the build failures: https://github.com/pavelfomin/spring-boot-rest-example/pulls
Notes:
- The repo must have the auto merge feature enabled obviously
- The tests quality (including Spring Boot integration tests) will determine the success rate
- It's all based on https://docs.github.com/en/code-security/tutorials/secure-your-dependencies/automate-dependabot-with-actions#automatically-approving-a-pull-request
The last part for the auto merge PRs is that it does not trigger the GH action to prevent an infinite loop.
When auto-merge completes, the merge commit pushed to master is attributed to GITHUB_TOKEN. GitHub deliberately suppresses workflow triggering for pushes made by GITHUB_TOKEN to prevent infinite recursive runs.
So gradle-nebula.yml (on: push: branches: [master]) — which does the publish + final tag + scripts/deploy-latest.sh — never fires for those merges.
GitHub's wording:
"When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN ... will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs."
Note: it applies to any GITHUB_TOKEN-driven merge.
I added a scheduled run to look for untagged commits. This part works as long as release is tagged in a reasonable time from the commit pushed to main.