FSH github-actions

Centrally-managed GitHub Actions for the FSH org: composite actions (reusable step bundles) and reusable workflows (callable jobs). Consumer repos reference these instead of carrying their own copies, so a change is made once here and rolled out everywhere via the moving @v1 tag.

What’s here

Composite actions — drop into a job’s steps:

Action

Purpose

setup-python

uv + pinned Python, with uv.lock caching

setup-node

Node from .nvmrc + yarn install

uv-sync

install project deps (uv sync <args>)

just-run

generic task runner — just <recipes>

setup-opa

install pinned opa + regal

pre-commit

cache + sync + pre-commit run --all-files

ecr-build-push

buildx + gha layer cache → push an image to ECR

ecs-run-migration

run the one-off migrate task, fail on nonzero exit

ecr-wait-replication

gate standby deploys on ECR cross-region replication

ecs-deploy

force-new-deployment + wait for steady state

Reusable workflows — call from a job’s uses:

Workflow

Purpose

pr-title

Conventional-Commit PR-title validation

release-python

release-please + build + publish to CodeArtifact (pypi)

release-npm

release-please + build + publish @fsh/* to CodeArtifact (npm)

docs

build a static site and deploy to Cloudflare Pages

deploy-ecs

build + push images, run migrations, redeploy ECS per region

New here? Start with Getting started. The full list of repo expectations these bake in is in Conventions.

What’s not centralised

Some things are deliberately left in each repo because they’re too repo-specific to share cleanly:

  • lint.yml as a whole workflow. Every repo’s lint job graph differs (simple python lint; multi-side be/fe/opa/render app gates; template bootstrap gates), so the orchestration stays per-repo — but it’s built from the actions above: a python repo’s lint job is setup-python → uv-sync → just-run (plus a pre-commit job); a node repo is setup-node → just-run; app gates add setup-opa. The recipes themselves live in each repo’s justfile.

  • A docs build that needs a service container (e.g. codegen-database’s Sphinx build talks to postgres) keeps a local docs workflow, since services: can’t pass through workflow_call.