/dockerized-service-release-deployment-workflow

name: dockerized-service-release-deployment-workflow
description: "Create a Dockerized-service release contract with clean GitHub Actions builds, main-anchored tags, immutable digest manifests, published-release deployments, production approval, health checks, and exact-digest rollback."
license: Apache-2.0
compatibility: Designed for Codex and portable to Hermes as instruction-only guidance for Docker or OCI images, GitHub Actions, GitHub Releases, container registries, and provider-specific deployment adapters. It bundles no provider credential, cloud adapter, or native Hermes runtime.
metadata:
  owner: gaelic-ghost
  repo: socket
  category: cloud-deployment-release
allowed-tools: Read Bash(rg:*) Bash(git:*) Bash(docker:*) Bash(gh:*) Bash(curl:*) Bash(uv:*) Bash(uvx:*)

Dockerized Service Release and Deployment Workflow

Purpose

Create or audit a durable release contract for a Dockerized backend or cloud service without treating a developer worktree or a production host as a build machine.

The default contract is:

1. Feature worktrees are development-only and may run native source tests, but never Linux artifact or image builds. 2. A clean GitHub Actions checkout of a version tag validates the release commit and builds the published OCI image. 3. The tag must resolve to a commit reachable from `origin/main`. 4. The registry digest, tag, commit, image reference, build run, and provenance/SBOM choices are written into a release manifest. 5. The workflow publishes a GitHub Release with that manifest attached: normal SemVer tags become normal releases, and recognized prerelease tags become GitHub prereleases. 6. Publishing the GitHub Release triggers deployment: normal releases target protected `production`; enabled prereleases target `test`. 7. The deployment job invokes a provider-specific adapter with `image@sha256:...` only after the selected environment permits it. 8. The adapter verifies service health and records the prior manifest/digest so rollback deploys a previous exact digest rather than rebuilding source.

This is a durable building-block change: it removes the ambiguity between a developer build, a CI artifact, and a deployed artifact. A project can later change registries or providers without weakening the tag-to-digest deployment contract.

When To Use

• Use this skill when adding or reviewing Dockerized-service release automation, an OCI registry publication path, GitHub Release deployment triggers, production approval gates, image-digest deployment, release manifests, health checks, or rollback guidance.
• Use it for backend services and cloud workloads regardless of application language when Docker or OCI images are the release artifact.
• Use `server-side-swift:docker-workflow` for Swift Dockerfile, Compose, Linux runtime, and image-entrypoint work.
• Use the official provider plugin or provider documentation for the final deployment adapter. This skill does not create cloud resources, configure a cloud account, or guess a provider command.

Source Check

Inspect the repository's Dockerfile, CI workflows, release process, registry settings, deployment files, health endpoint, provider configuration, and rollback procedures first. Then verify the current platform behavior against these official sources:

• [GitHub Actions environments](https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)
• [GitHub Actions OIDC](https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-cloud-providers)
• [GitHub Releases](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository)
• [GitHub Actions release-event triggers](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows)
• [GitHub Actions token-trigger behavior](https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow)
• [GitHub Container registry](https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry)
• [Docker GitHub Actions image publishing](https://docs.docker.com/build/ci/github-actions/push-multi-registries/)
• [Docker BuildKit attestations](https://docs.docker.com/build/metadata/attestations/)

Translate those sources into the actual project choices: registry, tag policy, environment policy, provider identity, health URL, and rollback command.

Build Ownership Preflight

Before starting an image build, record the deployment target's architecture, operating system, available memory, disk capacity, container runtime, and any provider constraints. Select the OCI platform from that evidence. For example, an Apple-silicon developer machine targeting an x86-64 Linux host builds `linux/amd64`; do not let the developer machine's architecture choose the release artifact by accident.

Build every cloud Linux archive and OCI image in a clean GitHub Actions checkout. Developer machines and production hosts must not build, cross-compile, or smoke-test cloud images. Record OCI artifacts by registry digest and record archive artifacts by SHA-256 checksum in the release manifest; deployment must consume that exact recorded identity. A production host may only pull or load a finished immutable artifact and run it. Do not clone application source, resolve dependencies, compile Swift, or run `docker build` on a production host.

One build owns its Docker client session until it exits. Preserve the original progress-producing shell or durable log stream; do not replace it with blind polling. When an agent must return for a build, GitHub Action, deployment approval, or health gate, it records the immutable identity (tag, digest, run, environment, and target), reuses a live matching host-native continuation while the gate remains pending and healthy, and performs one fresh inspection on wakeup. Continue only if every recorded identity equals the