gsadmin/ziti
1
0
Fork 0
mirror of https://github.com/openziti/ziti.git synced 2026-10-23 12:15:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

Correct quickstart release docs

Browse Source 
- documents the release: edited trigger that re-points :latest without rebuilding
- documents that :latest and CloudFront only follow GitHub's Latest release, and the force_latest/force_cloudfront overrides
- corrects the image tag format to X.Y.Z (no leading v)
- notes that each release branch must carry the workflow
This commit is contained in:
Paul Lorenz
2026-09-23 11:29:58 -04:00
parent de01dd226f
commit 8f9494fad6
1 changed files with 16 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
quickstart/README.md
+16 -6
View File
@@ -13,8 +13,16 @@ The enclosing project's GitHub releases are never updated and no Git tags are cr
### Release Process
A quickstart release is triggered automatically when a GitHub release of the enclosing project is
**published** (i.e., the `release: published` event fires, after the release assets have been uploaded).
A quickstart release is triggered automatically by GitHub release events of the enclosing project:
- `release: published` builds and pushes `openziti/quickstart:X.Y.Z` for a stable release tag `vX.Y.Z`
(prerelease tags such as `v2.1.0-pre1` are skipped).
- `release: edited` (e.g., a release is marked "Latest release") re-points `:latest` without rebuilding the image.
GitHub runs the copy of the workflow at the release tag's commit, so each release branch must carry this workflow.
The `:latest` tag and the `get.openziti.io` CloudFront Function only follow GitHub's "Latest release". Maintenance
releases of older minor versions publish their versioned image but leave `:latest` and CloudFront alone.
The release-quickstart workflow can also be invoked manually from the GitHub Actions UI
(`workflow_dispatch`) with an explicit release tag (e.g., `v1.6.7`). Use this when:
@@ -22,12 +30,14 @@ The release-quickstart workflow can also be invoked manually from the GitHub Act
- the automatic run failed for transient reasons and you want to rerun it, or
- you need to republish the quickstart artifacts for an existing release without cutting a new one.
Pass `force_latest: true` or `force_cloudfront: true` to move `:latest` or deploy CloudFront for a release that is
not GitHub's "Latest release".
Both jobs in the workflow are **idempotent and independently re-runnable**:
- The Docker image push step checks the registry first and skips if `openziti/quickstart:vX.Y.Z`
already exists. The `:latest` tag is only moved when the input tag matches GitHub's "Latest release"
flag (or you pass `force_latest: true` on a manual run).
- The CloudFront deploy is a re-publish each time; AWS handles repeated identical configurations
- The Docker image push step checks the registry first and skips the build if `openziti/quickstart:X.Y.Z`
already exists. `:latest` is only moved if it doesn't already point at the same digest.
- The CloudFront deploy is a re-publish each time it runs; AWS handles repeated identical configurations
cleanly.
If one job succeeds and the other fails, you can rerun the failed job alone from the Actions UI without