The release workflow publishes via GitHub API (patching draft to
published), which doesn't fire the release webhook. This meant the
Docker publish workflow was never triggered automatically.
Added explicit workflow dispatch for publish-docker.yml after release
publish, similar to how update-demo-server.yml was already dispatched.
Related to #797
GITHUB_TOKEN cannot dispatch workflows in the same repo. Mark the step
as continue-on-error so the release succeeds even if demo update fails.
Related to v4.34.1 release failure.
Publishing via gh api PATCH doesn't fire the release webhook,
so the update-demo-server workflow never triggered for v4.34.0.
Now explicitly dispatch the demo update workflow after publishing.
Related to #735
Without this flag, releases published from draft state don't
automatically become the 'latest' release on GitHub, causing
users to download outdated installer scripts.
The release pipeline now publishes the release automatically after
uploading all assets. This ensures downstream workflows (Docker publish,
Helm chart, demo server update) see the correct "latest" release and
don't skip due to the race condition where the draft wasn't published yet.
Draft releases cannot create tags via the GitHub API, resulting in
'untagged-xxx' releases. Fixed by creating the tag first, then
creating the draft release pointing to it.
See: https://github.com/cli/cli/issues/11589
- Preflight builds multi-arch images to staging tags on GHCR
- Publish workflow just retags staging → final (no rebuild)
- Reduces publish time from ~10min to ~1min
Docker images now build only after release is published, not during
the draft creation phase. This prevents users from getting updates
before the release is reviewed and approved.
Scripts like install.sh and install-sensor-proxy.sh are now attached
as release assets and downloaded from releases/latest/download/ URLs.
This ensures users always get scripts compatible with their installed
version, even while development continues on main.
Changes:
- build-release.sh: copy install scripts to release directory
- create-release.yml: upload scripts as release assets
- Updated all documentation and code references to use release URLs
- Scripts reference each other via release URLs for consistency
GitHub's API has a quirk: if you POST to /releases with a tag_name
that already exists as a git tag, it creates an 'untagged' release
instead of attaching to the existing tag.
The fix is to let the API create both tag and release together.
gh release create doesn't work properly when the tag already exists -
it creates an 'untagged' release instead of attaching to the existing tag.
Using the API directly with POST to /releases fixes this.
gh release create with --target was still creating untagged releases.
The fix is to create and push the git tag explicitly first, then
create the release which will properly attach to the existing tag.
The workflow was broken because it expected a tag to exist but the
documented process never created one. This caused gh release create
to fail with 'untagged' releases.
Changes:
- Workflow now creates the tag using --target flag
- Simplified release creation logic (no retry loops needed)
- Removed confusing comment about 'tag already exists'
This fixes the fundamental issue where the workflow and documented
process were out of sync.
