A pipeline, end to end

A workflow file in a repo (.gitea/workflows/build.yml) is all it takes. Because the job image already has the tools, the workflow is short:

name: build
on: { push: { branches: [main] } }
jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t registry.example.com/myapp:${GITHUB_SHA::7} .
      - run: |
          echo "<REDACTED>" | docker login registry.example.com -u <REDACTED> --password-stdin
          docker push registry.example.com/myapp:${GITHUB_SHA::7}

Note the tag: myapp:<short-git-sha>. Tagging by commit SHA means every image is immutable and traceable — you can always point at the exact commit an image was built from, and you never have two different builds wearing the same latest. (The registry password belongs in a repository secret, not in the file as shown — it's spelled <REDACTED> here for obvious reasons.)

Push to main → Gitea fires the workflow → the runner builds and pushes → the image is in the registry, ready for the cluster to pull.

Why we use this (SHA tags): mutable tags like latest are how you end up unable to answer "what's actually running?" Immutable, commit-pinned tags make deploys reproducible and rollbacks trivial — you're always referring to one specific, unchangeable artifact.