|
| 1 | +# Release Container Workflow Sample |
| 2 | + |
| 3 | +This sample workflow demonstrates a complete release pipeline that combines semantic versioning, container publishing, and automated tagging. It's designed to be copied into your project's `.github/workflows/` directory and customised for your specific needs. |
| 4 | + |
| 5 | +## Overview |
| 6 | + |
| 7 | +The workflow performs the following steps: |
| 8 | + |
| 9 | +1. **Semantic Release**: Analyses commits since the last release to determine if a new version should be created, and if so, generates a new Github release with an automatically generated changelog. |
| 10 | +2. **Container Publishing**: Builds and pushes a container image with an `edge` tag (we avoid latest, so this is a pre-release build) |
| 11 | +3. **Semver Tagging**: If a release was created, promotes the edge image to semantic version tags (e.g., `1.2.3`, `1.2`, `1`) |
| 12 | + |
| 13 | +## Prerequisites |
| 14 | + |
| 15 | +- Your repository must follow [conventional commit](https://conventionalcommits.org/) format |
| 16 | +- We recommend `samples/check.pr-title.yaml` to enforce this on pull requests |
| 17 | +- Your repository settings should only allow squash merges, and use the PR title as the commit message for commit messages to be correctly parsed by semantic-release |
| 18 | +- You need a `samples/release.config.js` in your repository root to configure semantic-release |
| 19 | +- You need a `Dockerfile` in your repository root (or update the `dockerfile` parameter) |
| 20 | + |
| 21 | +## Workflow Jobs |
| 22 | + |
| 23 | +### semantic-release |
| 24 | + |
| 25 | +Uses the [`semantic-release.yml`](../semantic-release.md) reusable workflow to: |
| 26 | + |
| 27 | +- Install and run semantic-release |
| 28 | +- Create GitHub releases with automatically generated changelogs |
| 29 | +- Output `release-created` (boolean) and `release-tag` (version string) |
| 30 | + |
| 31 | +### publish-container |
| 32 | + |
| 33 | +Uses the [`publish-container.yml`](../publish-container.md) reusable workflow to: |
| 34 | + |
| 35 | +- Build a multi-architecture container image |
| 36 | +- Tag it with SHA, timestamp, and "edge" |
| 37 | +- Push to the specified container registry |
| 38 | + |
| 39 | +**Parameters:** |
| 40 | +- `image-name`: Name of your container image |
| 41 | +- `image-description`: Description for the image |
| 42 | +- `registry`: Container registry (e.g., `ghcr.io`, `docker.io`) |
| 43 | +- `context`: Build context path (usually `.`) |
| 44 | +- `dockerfile`: Path to Dockerfile |
| 45 | +- `platforms`: Target architectures (comma-separated) |
| 46 | + |
| 47 | +### semver-container |
| 48 | + |
| 49 | +Uses the [`semver-container.yml`](../semver-container.md) reusable workflow to: |
| 50 | + |
| 51 | +- Promote the edge image to semantic version tags |
| 52 | +- Only runs if `semantic-release` created a new release |
| 53 | + |
| 54 | +**Parameters:** |
| 55 | +- `image-name`: Must match the `publish-container` job |
| 56 | +- `registry`: Must match the `publish-container` job |
| 57 | +- `tag`: Release tag from semantic-release (do not modify) |
| 58 | + |
| 59 | +### Version Pinning |
| 60 | + |
| 61 | +For production use, pin to specific versions: |
| 62 | + |
| 63 | +```yaml |
| 64 | +uses: health-informatics-uon/workflows/.github/workflows/semantic-release.yml@v1.3.0 |
| 65 | +``` |
| 66 | +
|
| 67 | +Check the [releases](https://github.com/health-informatics-uon/workflows/releases) for available versions. |
| 68 | +
|
| 69 | +## Usage |
| 70 | + |
| 71 | +1. Copy `samples/release.container.yaml` to your repository's `.github/workflows/release.yaml` |
| 72 | +2. Copy `samples/release.config.js` to your repository root and customise it for your repository |
| 73 | +3. Update the workflow parameters in `release.yaml` (image name, etc.) |
| 74 | +4. Ensure your repository follows the prerequisites (conventional commits, squash merges, etc.) |
0 commit comments