WeMove Reusable CI Workflows

A collection of reusable GitHub Actions workflows (on: workflow_call) shared across WeMoveEU projects. Caller repositories reference these by path and version tag from their own .github/workflows.

Using these workflows

Always pin to a version tag — the current latest is @v12:

uses: WemoveEU/ci-workflows/.github/workflows/docker-build.yml@v12

A new vN tag is pushed on each release. Pin to a tag (not a branch) so callers opt in to changes deliberately.

The workflows available:

• docker-build.yml — build and push a Docker image to GitHub Container Registry.
• deploy-strapi.yml — build and deploy a Strapi backend + frontend.
• notify.yml — post a Slack notification.
• python-build.yml — build a Python package with uv.

---

docker-build.yml

Builds a Docker image and pushes it to GitHub Container Registry (ghcr.io/<name>). This is the foundational workflow that the others build on. It supports staging and production environments via its tagging strategy.

Inputs

• dockerfile: Path to the Dockerfile used for building the image. Default Dockerfile.

• name: Name of the image in the registry (pushed to ghcr.io/<name>). Default ${{github.repository}}.

• dir: The root of app sources / build context. Use if your app is in a subdirectory, e.g. frontend. Default ..

• overlay: Name of an artifact to unpack over the checked-out source before building (e.g. env files). Use a unique name based on ${{github.run_id}} to avoid races between concurrent runs. The artifact is deleted after it is unpacked.

• prepare: Shell commands run (via bash) after unpacking the overlay, before building the image.

• args: Docker build args (one variable, or multiline format), passed to the build-args input of docker/build-push-action.

• production_branch: The name of the production branch. Default main.

Secrets

• personal_token: Optional personal access token used to check out private repositories and submodules. Falls back to github.token when not provided.

Image tagging strategy

Tags are generated by docker/metadata-action from the git context:

• feature/* branches → feature tag + the branch ref
• Semver tags (v1.2.3) → version / major.minor / major tags
• Push to production_branch → latest
• Push to the default branch when it is not the production branch → staging

If the ref matches none of these rules (e.g. a release/* or otherwise unrecognised branch), no tag is produced. In that case the image is built but not pushed — the run still validates the Dockerfile, and a warning is emitted — rather than failing with tag is needed when pushing to registry.

Jobs

The release job runs on ubuntu-latest with contents: read, packages: write, and actions: write permissions (the last is needed because the overlay artifact is deleted via the Actions API). Its steps:

1. Checkout Code: actions/checkout@v7 clones the repository and its submodules (fetch-depth: 20).

2. Apply Overlay: If overlay is set, actions/download-artifact@v8 downloads it and geekyeggo/delete-artifact@v6 removes it. Create the overlay in the caller with actions/upload-artifact@v4; its files are unpacked into the project directory. See this example.

3. Run Prepare Script: Executes the prepare shell commands if provided.

4. Generate Image Tag: docker/metadata-action@v6 produces tags per the strategy above.

5. Set up Docker Buildx: docker/setup-buildx-action@v4.

6. Login to GitHub Container Registry: docker/login-action@v4 (authenticates to ghcr.io with GITHUB_TOKEN).

7. Build and Push: docker/build-push-action@v7 builds from dir using dockerfile and pushes the generated tags.

Sample usage

name: Deploy
on:
  push:
    branches:
      - main
      - "release/*"
jobs:
  release:
    uses: WemoveEU/ci-workflows/.github/workflows/docker-build.yml@v12
    with:
      production_branch: ${{vars.CI_PRODUCTION_BRANCH}}
      dockerfile: server/Dockerfile
      dir: server
      name: crm/server

---

deploy-strapi.yml

Orchestrates a Strapi deploy by calling docker-build.yml twice — backend first (backend/Dockerfile, image <repo>/backend), then frontend (frontend/Dockerfile, image <repo>/frontend). Between them, a wait-for-backend job polls the live backend until it is ready.

Inputs

• backend_args: Docker build args for the backend image. Default ''.
• frontend_args: Docker build args for the frontend image. Default ''.
• production_branch: The name of the production branch. Default main.
• deploy_marker: Filename in the Strapi public folder whose presence means the backend is deployed. The health check polls https://strapi.${{vars.DOMAIN}}/<deploy_marker> and only runs when this input is provided.

Secrets

• personal_token: Optional personal access token, forwarded to docker-build.yml for private repositories and submodules.

Notes

• The wait-for-backend job selects its GitHub Environment dynamically: production when on the vars.CI_PRODUCTION_BRANCH branch or a tag starting with v; otherwise staging.
• Overlay names are made run-unique with ${{github.run_id}} (backend_env_<run_id>, frontend_env_<run_id>) to avoid collisions between concurrent runs.
• Calling repositories must define the repository variables vars.CI_PRODUCTION_BRANCH and vars.DOMAIN.

---

notify.yml

Posts a Slack notification (green on success, red on failure) via slackapi/slack-github-action@v3. Call it as a final step from a caller workflow.

Secrets

• slack_webhook_url: Slack channel incoming-webhook URL (required).

---

python-build.yml

Builds a Python package with uv: checks out the repo (actions/checkout@v7), installs uv (astral-sh/[email protected]), and runs uv build. Takes no inputs.

---

Releases

• v12 — docker-build.yml: when no tag rule matches the ref, the image is now built without pushing (with a warning) instead of failing with tag is needed when pushing to registry. Registry login is skipped in that case.
• v11 — README rewritten as a repo overview covering all four workflows; action versions corrected.