The integration_tests job restores the pre-built frontend dist from
cache and copies it to the embed location, but then runs make build
which unconditionally rebuilds the frontend via npm — failing because
node_modules aren't installed. Use go build directly since the
frontend is already embedded.
Restored original license signing key from backup - key was never
compromised (private repo). Removes unnecessary dual-key complexity:
- Remove legacyPublicKey and SetLegacyPublicKey from license.go
- Simplify signature verification to single key
- Remove EmbeddedLegacyPublicKey from pubkey.go
- Remove PULSE_LICENSE_LEGACY_PUBLIC_KEY from Dockerfile and workflows
- Remove dual-key test
- Simplify mock.env
Previously, preflight only built amd64 images, so multi-arch failures
(like the QEMU timeout in 5.0.5) weren't caught until after the
release was published.
Now preflight builds linux/amd64,linux/arm64 staging images. If
multi-arch build fails, the release pipeline stops before publishing.
Combined with the Dockerfile fix (forcing amd64 for build stages),
this ensures Docker build issues are caught early.
- Check if tag exists before creating (skip if pointing to HEAD, fail with
helpful message if pointing elsewhere)
- Check if draft release exists before creating (update existing draft)
- Add --clobber to all asset uploads to allow re-uploading on retry
- Add HandleLicenseFeatures handler that was missing from license_handlers.go
- Add /api/license/features route to router
- Update AI service and metadata provider
- Update frontend license API and components
- Fix CI build failure caused by tests referencing unimplemented method
The promote-floating-tags and helm-pages workflows now trigger
automatically via workflow_run when publish-docker.yml completes,
instead of being dispatched immediately by create-release.yml.
This ensures Docker images are fully available before:
- Floating tags (rc, latest, major.minor) are promoted
- Helm chart smoke tests try to pull the image
Key changes:
- promote-floating-tags.yml: Add workflow_run trigger, extract tag
from triggering workflow, wait for BOTH pulse and agent images
- helm-pages.yml: Add workflow_run trigger, extract version from
triggering workflow
- create-release.yml: Remove manual dispatch for these workflows
Skip arm64 QEMU emulation in preflight tests - staging images are only
used for integration tests which run on amd64. This cuts ~20-30 minutes
off the release pipeline.
Multi-arch Docker images are still built in the final release job via
publish-docker.yml.
- Remove 'release: published' triggers from publish-docker, promote-floating-tags, and helm-pages workflows
- All these workflows now only run via workflow_dispatch, triggered by create-release.yml in sequence
- Add image availability check in promote-floating-tags to wait for Docker images
- create-release.yml now dispatches: publish-docker, promote-floating-tags, helm-pages, update-demo-server
- This prevents the race condition where workflows triggered by release event run before Docker images are ready
- Update VERSION to 5.0.0-rc.1
- Add prerelease detection to create-release workflow
- Mark RC releases as prereleases on GitHub (not 'latest')
- Update publish-docker workflow to skip :latest tag for RCs
- Support -rc.N, -alpha.N, and -beta.N version suffixes
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.
