Table of Contents

Container Release Publishing

This article documents the tag-driven container release workflow for the repository-maintained template image.

The published image is intended as release evidence for the template repository. It is not required for local template development, and generated consumer applications may choose their own registry, image name, and deployment process.

Published Image

The release workflow publishes the repository image to GitHub Container Registry:

ghcr.io/cdcavell/netcoreapplicationtemplate

A tag push matching v*.*.* starts the container release workflow.

Stable semantic version tags publish:

ghcr.io/cdcavell/netcoreapplicationtemplate:<major>.<minor>.<patch>
ghcr.io/cdcavell/netcoreapplicationtemplate:<major>
ghcr.io/cdcavell/netcoreapplicationtemplate:latest

Prerelease tags publish the full version tag only and do not update latest or the major tag.

Release Safety Gate

The publish job targets the container-publish GitHub environment. Configure that environment with required reviewers before the first production publish so the initial GHCR publication has a manual approval gate.

Recommended environment settings:

  • Environment name: container-publish
  • Required reviewers: repository owner or maintainer
  • Deployment branches and tags: allow protected release tags as appropriate

Build and Scan Flow

The workflow builds the Docker image from the repository Dockerfile, scans the built image, generates release evidence, and only then publishes.

Release evidence includes:

  • Trivy vulnerability scan output.
  • Trivy SARIF results uploaded to GitHub code scanning.
  • SPDX JSON software bill of materials.
  • Build provenance metadata generated by GitHub artifact attestation.
  • Cosign keyless signature for the published image digest.

Critical and High vulnerabilities fail the build unless the repository explicitly documents an accepted-risk exception in a future change.

Permissions Model

The workflow keeps default permissions read-only and grants write permissions only in the jobs that need them.

The publish job requires:

  • packages: write to push the image to GHCR.
  • contents: write to create or update the GitHub Release and attach evidence.
  • id-token: write to support keyless signing and provenance attestation.
  • attestations: write to publish artifact provenance metadata.
  • security-events: write to upload SARIF vulnerability results.

Health Probe Contract

The container image listens on port 8080.

Health probe paths are:

/health/live
/health/ready

The Dockerfile intentionally delegates active HTTP health probing to Docker Compose, Kubernetes, load balancers, or hosting infrastructure rather than adding probe-only tools such as curl or wget to the runtime image.

Local Verification

Before tagging a release, build the local image:

docker build -t projecttemplate-web:dev .

Run the container:

docker run --rm -p 8080:8080 projecttemplate-web:dev

Verify the probe contract:

curl http://localhost:8080/health/live
curl http://localhost:8080/health/ready

Release Checklist

[ ] Confirm the release tag follows semantic versioning.
[ ] Confirm CI and template smoke tests are passing.
[ ] Confirm Docker build succeeds locally or in CI.
[ ] Confirm Trivy scan has no unaccepted Critical or High findings.
[ ] Confirm SBOM and scan artifacts are attached to the release.
[ ] Confirm the image digest is signed.
[ ] Confirm provenance attestation is present.
[ ] Confirm GHCR tags match the release version policy.
Edit this page