ci-workflows

Shared reusable Forgejo Actions workflows for the TRB org. Instead of every repo carrying its own copy of the same CI logic (which drifts — different pinned action SHAs, polaris scores, missing jobs), repos call a workflow from here.

Requires Forgejo >= 15 and runner >= 12.2 (reusable-workflow expansion).

validate-manifests.yaml

Kustomize build -> kubeconform -> polaris, plus a commitlint job. Used by the *-config GitOps repos.

# .gitea/workflows/validate.yaml in a config repo
name: 'Validate config files'
on:
  workflow_dispatch:
  push:
  pull_request:

jobs:
  validate:
    uses: TRB/ci-workflows/.forgejo/workflows/validate-manifests.yaml@v1.0.0
    secrets: inherit
    with:
      polaris-min-score: 82   # optional, default 100

Inputs: polaris-min-score (number, default 100), kustomize-path (string, default .), run-commit-messages (boolean, default true).

build-publish.yaml

Build a container image -> commitlint -> semantic-release -> tag & push to registry.trb.nrw. Used by the Node-based app/image repos.

# .gitea/workflows/build.yml in an app repo
name: 'Build and publish container image'
on:
  workflow_dispatch:
  push:
  pull_request:

jobs:
  build:
    uses: TRB/ci-workflows/.forgejo/workflows/build-publish.yaml@v1.0.0
    secrets: inherit
    # image-name defaults to the repo name, containerfile to "Containerfile"

Inputs: image-name (string, default = repo name), containerfile (string, default Containerfile).

Notes

• secrets: inherit passes the caller's secrets (REGISTRY_TRB_NRW_USER / _PASSWORD, GITHUB_TOKEN) through to the reusable workflow.
• Both workflows enable npm caching (setup-node cache: npm) against the shared fleet cache server, so the commitlint / semantic-release deps are not re-downloaded on every run.
• Renovate (via local>TRB/renovate-config) bumps the pinned action SHAs here in one place, instead of once per consuming repo.

Versioning & rollout

Consumers pin an immutable tag (@v1.0.0), never @main or a moving major tag (@v1). This is deliberate:

• A push to main here does not change any consuming repo. Cut a new tag (e.g. v1.0.1) to release.
• Renovate then opens one bump PR per consuming repo. Each PR runs that repo's CI against the new workflow version before merging, and default.json only automerges green PRs — so a breaking change surfaces as red, unmerged PRs rather than silently breaking the whole fleet.

Tagging: git tag v1.0.x && git push --tags. Use semver — breaking input/ behaviour changes get a new major; consumers move to @v2.0.0 deliberately.