Workflow updater
The workflow manager lets you install and update your CI workflows from their upstream templates by hand (make workflows-update). The workflow updater automates the update side: on a schedule it runs make workflows-update for you and opens a pull request whenever a managed workflow has changed upstream. It is what replaces Dependabot for the files under .github/workflows/.
Tip
TL;DR — Install with make workflows-install W=workflow-updater, set up the GitHub App it authenticates with, and from then on you get a pull request whenever your managed workflows drift from upstream. Locally modified workflows are left untouched.
- What it does
- Installing it
- The GitHub App it needs
- When it runs
- What a run does
- The pull request it opens
- Why not Dependabot
workflow-updater.yml is a workflow ncmake ships itself (source ncmake, like release.yml). Once installed and scheduled it:
- fetches the ncmake modules (
make dev-init), - refreshes the managed workflows from their upstream templates (
make workflows-update), - opens a pull request if anything changed.
It only ever touches workflows that are managed (listed in .ncmake-workflows.json) and not locally modified. Anything you edited by hand is left alone, exactly as with a manual make workflows-update.
It is a normal ncmake-provided workflow, so it installs through the manager:
make workflows-install W=workflow-updater
git add .github/workflows/Commit and merge that like any other workflow adoption. From then on workflow-updater.yml lives in .github/workflows/ and is itself managed, so a later run keeps it up to date too.
The updater changes files under .github/workflows/, which the automatic GITHUB_TOKEN may not push, and its commit must be verified when your branch protection requires signed commits. A GitHub App covers both: its token pushes the workflow files, and the pull request is committed as the app's bot with a verified signature. It also triggers your CI checks (a real actor, unlike the GITHUB_TOKEN), so you see whether a template update breaks anything before you merge.
Important
Set the app up once, following A GitHub App for the workflow updater. It needs Contents, Pull requests and Workflows (each Read and write), installed on the repository, with its Client ID and private key stored as the NCMAKE_UPDATER_CLIENT_ID and NCMAKE_UPDATER_PRIVATE_KEY secrets. Without it the run fails the moment there is a workflow change to push.
-
On a schedule: daily at 05:30 UTC (the
cronline in the workflow). GitHub runs scheduled workflows on a best-effort basis and delays them under load, so in practice the run starts a couple of hours after the cron time, not on the minute. That is expected, not a failure: it only needs to catch an upstream change within a day, so the delay does not matter here. A run with nothing to do is a quiet no-op, and standard runners are free on public repositories, so a daily check costs nothing. -
On demand: Actions tab → ncmake workflow update → Run workflow (
workflow_dispatch).
The manual trigger only appears once the workflow is on your default branch. That is how workflow_dispatch works, and it is why installing the updater means merging it to main first. It stays idle until the schedule fires or you trigger it.
The single job mints the app token, checks out the repository, runs make dev-init then make workflows-update, and hands any resulting changes to the pull-request step. ubuntu-latest already carries make, git, curl and python3, so there is nothing to set up. The commit is signed by the app's bot (so it is verified) and carries a matching Signed-off-by, so the DCO check passes.
If make workflows-update changed anything, the updater opens a pull request titled ci: update managed CI workflows from upstream on the branch ncmake/ci/workflow-update, containing only the refreshed files under .github/workflows/ (plus the updated lock). Review the diff and merge it like the original adoption.
If nothing changed upstream, no pull request is opened and the run is quiet.
Once you merge that pull request, the updater deletes its own ncmake/ci/workflow-update branch right away, so it never leaves a stale branch behind between runs. This is the updater tidying up after itself — it is a different mechanism from the repository-wide Automatically delete head branches setting, which removes the head branch of every merged pull request. Either one keeps this branch from piling up; enabling both is harmless, as the branch is simply already gone by the time the other would act.
Dependabot's github-actions ecosystem and this updater both change the same files, so running both makes them fight: each edit flags the workflows as locally modified for the other. The upstream templates already keep their action pins current, and make workflows-update brings those along, so the updater is the single source of truth. Remove the github-actions ecosystem from dependabot.yml and let the updater own .github/workflows/; keep npm and Composer under Dependabot.
