You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/packages/working-with-a-github-packages-registry/working-with-the-container-registry.md
+17-15Lines changed: 17 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -92,8 +92,7 @@ The easiest way to connect a repository to a container package is to publish the
92
92
93
93
To connect a repository when publishing an image from the command line, and to ensure your `GITHUB_TOKEN` has appropriate permissions when using a GitHub Actions workflow, we recommend adding the label `org.opencontainers.image.source` to your `Dockerfile`. For more information, see “[Labelling container images](#labelling-container-images)” in this article and “[AUTOTITLE](/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions).”
94
94
95
-
## Pulling container images
96
-
## CI/CD tagging strategy for multi-environment deployments
95
+
## CI/CD tagging strategy for container images
97
96
98
97
A consistent tagging strategy helps trace container images back to their source commits, simplify environment promotion, and improve rollback reliability.
99
98
@@ -102,7 +101,7 @@ A consistent tagging strategy helps trace container images back to their source
102
101
Apply multiple tags to the same image digest during each build so deployments can reference images by stability level or exact provenance.
103
102
104
103
| Tag pattern | Example | Purpose |
105
-
|---|---|---|
104
+
|---|---|---|
106
105
| Commit SHA (short) |`sha-a1b2c3d`| Immutable reference suitable for production rollbacks |
107
106
| Branch name |`main`, `release-1.4`| Mutable tag that tracks the latest build for a branch |
108
107
| Semantic version |`v1.4.2`| Human-readable release version |
@@ -112,10 +111,15 @@ Apply multiple tags to the same image digest during each build so deployments ca
112
111
> Avoid relying solely on the `latest` tag in automated deployment pipelines. Because `latest` is mutable, it does not provide reliable traceability between deployments and source revisions.
113
112
114
113
### Applying multiple tags in a GitHub Actions workflow
114
+
> [!NOTE]
115
+
> Avoid relying solely on the `latest` tag in automated deployment pipelines. Because `latest` is mutable, it does not provide reliable traceability between deployments and source revisions.
115
116
116
-
Use the `docker/metadata-action` action to generate image tags automatically from Git context and pass them to `docker/build-push-action`.
117
+
### Applying multiple tags in a GitHub Actions workflow
117
118
119
+
Use the `docker/metadata-action` action to generate image tags automatically from Git context and pass them to `docker/build-push-action`.
118
120
```yaml
121
+
{% data reusables.actions.actions-not-certified-by-github-comment %}
122
+
119
123
jobs:
120
124
build-and-push:
121
125
runs-on: ubuntu-latest
@@ -126,35 +130,33 @@ jobs:
126
130
127
131
steps:
128
132
- name: Check out repository
129
-
uses: actions/checkout@v4
133
+
uses: {% data reusables.actions.action-checkout %}
tags: {% raw %}${{ steps.meta.outputs.tags }}{% endraw %}
158
+
labels: {% raw %}${{ steps.meta.outputs.labels }}{% endraw %}
156
159
```
157
-
158
160
All tags generated during the workflow reference the same image digest. This allows deployments to promote existing images between environments without rebuilding the container image.
0 commit comments