Skip to content

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.md entry in .github, because consumers have no pinned version to stay on while they catch up.

The rules and their reasoning: understanding reusable workflows.

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:

Terminal window
gh api repos/alma-mobility-marketplaces/.github/actions/permissions/access \
--jq '.access_level' # expect: "organization"