A GitHub release packages a named, versioned handoff from CI to continuous delivery. It is associated with a Git tag, can include generated release notes and deployment artifacts, and gives teams a traceable record of what changed, who approved it, and what should move toward production. section 8.5 section 8.5.8
Create a release after required CI workflows succeed, rather than treating artifact publication alone as deployment. With GitHub flow or trunk-based development, a merged pull request to the main branch can provide the reviewed, traceable point at which a version is released. A release event can then start a separate CD workflow. section 8.5.8 section 9.1.2
Use a release to make the deployment boundary explicit:
- Assign a version and collect the artifacts required for deployment, such as packages, container-related deployment descriptors, or other produced files. section 8.8 section 8.6.5
- Preserve traceability from deployed environments back to the responsible change, contributor, and version-control history. section 8.5
- Trigger CD from a published release so the deployment workflow retrieves one consistent, versioned set of production artifacts. section 9.1.2 section 9.4
- Create releases manually when separation of duties matters, or automate them after successful CI when release creation is part of the delivery path. section 8.5.8
Create a release after publishing container images
A workflow can react when a tagged container package is published, reject empty tags, serialize releases by version, retrieve the image versions, substitute them into Kubernetes deployment files, and attach those files to a generated-notes release. The published release then provides the artifacts and version consumed by CD. section 8.5.8 section 8.6.5
Listing 8.17 Creating a release automatically
name: "chapter 08: create release"
permissions:
actions: write
packages: write
contents: read
on:
registry_package:
types: [published]
env:
deploymentFolder: 'deployment-automation'
GH_TOKEN: ${{ secrets.EXTENDED_ACCESSTOKEN }} #required for gh tool
This workflow header shows an automated release job triggered by container-package publication and declares the permissions and token access it needs. section 8.5.8
For a public GitHub Action, publishing a release can also publish it to the GitHub Marketplace. GitHub checks action metadata such as a unique name, description, branding, and README; publishing requires acceptance of the Marketplace Developer Agreement. Generated release notes can summarize pull requests and first-time contributors. section 4.4.2
Keep release creation distinct from the later decision to reveal new software to users. Deployment strategies require separating deployment from release, even when a GitHub release is the automation boundary that initiates deployment work. section 9.3 section 9.4
