How CI runs across our repos
GitHub Actions is our CI/CD platform everywhere. What makes it worth a page here is that
most of what runs in your repository is not defined in your repository — it is called
from .github, the
organisation’s special repository, where one definition serves every consumer.
So when a check you did not write starts failing, the place to look is usually not your repository.
That is the whole point of this page. Everything below is a pointer, because
.github/docs/
already documents the workflows properly — the caller contract for each one, the prefix
convention, the security checklist, the catalogue — and it is maintained alongside the
workflows themselves.
Two pinning rules that look inconsistent and are not
Section titled “Two pinning rules that look inconsistent and are not”Internal reusable workflows are referenced at @main, with no version pin. Third-party
actions are pinned by commit SHA.
The difference is the trust boundary. Inside the organisation, a moving reference means a fix reaches every consumer at once, and there is no per-workflow versioning to maintain. Outside it, a moving reference means someone else can change what runs in our CI — so a tag, which can be repointed, is not good enough.
Two consequences follow, and both bite:
- Renaming a shared workflow file breaks every caller, silently, with no error that points at the cause. Treat the filenames as an API.
- Changing a shared workflow needs a
CHANGELOG.mdentry in.github, because consumers have no pinned version to stay on while they catch up.
The rules and their reasoning: understanding reusable workflows.
Ecto-1 spans four repositories
Section titled “Ecto-1 spans four repositories”Worth knowing here because no single repository documents the whole chain. A prod deploy
tags a release and fires a repository_dispatch; that triggers a second workflow, which
runs the claude-changelog
Action over the tag diff and posts the result through
ecto-1-slack. Both
workflows are in .github.
The aim is a changelog entry that reads well for non-technical people as well as engineers — the thing nobody writes by hand consistently.
One setting whose failure mode gives no hint
Section titled “One setting whose failure mode gives no hint”The .github repository’s Actions access must be organisation-wide. If it is not, every
external caller fails with workflow was not found and nothing suggests that access is
the cause. If a repository’s shared checks vanish all at once, check this first:
gh api repos/alma-mobility-marketplaces/.github/actions/permissions/access \ --jq '.access_level' # expect: "organization"Where to go next
Section titled “Where to go next”- Calling a reusable workflow, and adding one
- The workflow catalogue and the filename prefixes
- Org-wide branch, commit, PR and CI policy — note that “branch off the default branch” is not “branch off
main” everywhere; the repository map has the per-repository answer setup-ci-runner— the composite Action that bootstraps runner tooling, including the supply-chain guard- How supply-chain security works — where the scan results go