Skip to content

ci(dependabot): added Dependabot auto-merge caller workflow - #168

Merged
karlspace merged 1 commit into
mainfrom
ci/dependabot-maintenance
Oct 10, 2026
Merged

karlspace merged 1 commit into
mainfrom
ci/dependabot-maintenance

Conversation

@karlspace

Copy link
Copy Markdown
Contributor

Why

Dependabot opens weekly NuGet update PRs here (9 are open right now), and dotnet-release.yml already builds and tests each of them on the PR. But the repository had no caller of the shared docker-maintenance-dependabot.yml workflow, so nothing decided on them: green PRs waited for a manual merge, and nothing marked which ones were safe to merge.

What

New .github/workflows/dependabot-maintenance.yml, which calls bauer-group/automation-templates/.github/workflows/docker-maintenance-dependabot.yml@main (based on the own-build-and-test-workflow.yml example):

  • No paths: filter. Every Dependabot PR reaches the module, whatever its ecosystem, and gets an explicit decision: it is either merged or left open with an annotation and a job summary. types: [opened, synchronize, reopened, ready_for_review].
  • required-workflows: .github/workflows/dotnet-release.yml. Its pull_request run builds BAUERGROUP.Shared.slnx and runs the tests on windows-latest, runs the Avalonia headless tests on ubuntu-latest, and packs the libraries (📋 Validate Package (PR)). That run must conclude success.
  • dotnet-release.yml is unchanged. Its PR paths: already cover every file the NuGet updater changes in this repository. The repository uses central package management, so Dependabot writes Directory.Packages.props, or a VersionOverride in src/**/*.csproj. Recent Dependabot PRs (deps(dotnet): Bump Avalonia, Avalonia.Headless.XUnit and Avalonia.Themes.Fluent #156, deps(dotnet): Bump coverlet.collector and Moq #164, deps(dotnet): Bump Sentry and Sentry.NLog #166) only touched Directory.Packages.props and all of them started the release workflow. There is no packages.lock.json, global.json or dotnet-tools.json, and Dependabot never writes nuget.config.
  • merge-update-types: patch, merge-method: squash, auto-approve: true, secrets: inherit.
  • Permissions: contents: write, pull-requests: write, checks: read, statuses: read, actions: read.

Compatibility

  • NuGet: a patch update that dotnet-release.yml built and tested successfully is merged automatically. Minor and major updates stay open for review. Under the 0.x rule a 0.y.z minor or a 0.0.z patch counts as major, and in a grouped update the strictest dependency decides. PRs with failing CI, such as deps(dotnet): Bump CefSharp.Wpf.NETCore from 152.0.60 to 152.0.100 #160 and deps(dotnet): Bump the microsoft group with 1 update #163 today, stay open with a notice.
  • GitHub Actions: these updates, and any PR that changes .github/, are never merged automatically (the module's own guard). They get a notice and stay open for a manual merge.
  • Releases: the NuGet commit prefix is deps(dotnet), and .github/config/release/semantic-release.json maps deps to a PATCH release. Every auto-merged update therefore leads to a new NuGet release. It is cut with the next push to main that is not made by GITHUB_TOKEN, or with a manual run of dotnet-release.yml, because the merge itself starts no push workflow. The prefix is left unchanged on purpose.
  • This PR only adds a file under .github/. The release workflow's push trigger ignores .github/**, so merging this PR cuts no release.

Test

  • The YAML parses, and the inputs and permissions were checked against the reusable workflow's workflow_call interface on automation-templates@main.
  • The PR CI on this branch runs the new caller. Its reusable job is skipped by the module's job filter because this PR is not from Dependabot, which shows that GitHub accepts the caller (no startup failure). The first Dependabot PR (re)opened or rebased after the merge exercises the full decision path.

NuGet updates from Dependabot piled up as open PRs (9 open right
now) although dotnet-release.yml already builds and tests them on
the PR. The repository had no caller of the shared
docker-maintenance-dependabot workflow, so nothing ever decided on
them.

* New .github/workflows/dependabot-maintenance.yml calls the
  reusable workflow from bauer-group/automation-templates@main
* No paths filter: every Dependabot PR, whatever its ecosystem,
  reaches the workflow and gets an explicit decision with an
  annotation instead of silently staying open
* required-workflows = dotnet-release.yml: its pull_request run
  builds the whole solution, runs the tests on Windows and the
  Avalonia tests on Linux and packs the libraries. Its PR paths
  already cover every file the NuGet updater changes here
  (Directory.Packages.props, VersionOverride in src/**/*.csproj),
  so it needed no change
* Patch updates only, squash merge, auto-approve; GitHub Actions
  updates and other .github/ changes stay manual (module guard)
* Permissions: contents/pull-requests write for merge and approve,
  checks/statuses/actions read for the CI state

The NuGet prefix deps(dotnet) maps to a PATCH release in the
semantic-release config, so every merged update cuts a NuGet
release with the next push to main that is not made by
GITHUB_TOKEN (the merge itself starts no push workflow).
@karlspace
karlspace merged commit 8800dd4 into main Oct 10, 2026
6 checks passed
@karlspace
karlspace deleted the ci/dependabot-maintenance branch October 10, 2026 20:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant