Use --notes-file instead of --notes with variable expansion to prevent
bash from interpreting markdown code blocks as shell commands.
Fixes the error where installation examples like:
```bash
docker pull rcourtman/pulse:v4.29.0
```
Were being executed as actual commands during release creation.
Related to #671
actions/checkout@v4 does not fetch tags by default, causing the
previous tag lookup to fail and fall back to comparing with the
first commit SHA. Added fetch-depth: 0 to fetch all history including tags.
Just use the latest tag directly instead of trying to exclude the current version.
Since we're generating release notes BEFORE creating the tag, the latest tag
will always be the previous release.
The script was failing because git describe --tags --abbrev=0 HEAD^ returns
the current HEAD commit SHA when no tag exists before HEAD, resulting in
comparing HEAD..HEAD which has zero commits.
Now using git tag --sort=-version:refname to get the latest tag (excluding
the version being released) which will properly compare v4.29.0 with v4.28.0.
- Capture script exit code before checking
- Show full error output if script fails
- Prevents silent failures where error is hidden in temp file
Related to #671 (automated release workflow)
- Replace sed with awk for more reliable multiline extraction
- Use temp file to capture full script output
- Extract content between separator lines correctly
- Fixes empty release notes in draft releases
Previous issue: sed pattern wasn't matching the separator lines,
resulting in empty RELEASE_NOTES variable.
New approach: Use awk to capture everything between the two separator
lines, handling multiline content properly.
Related to #671 (automated release workflow)
- Create scripts/generate-release-notes.sh to auto-generate release notes from git commits
- Supports both Anthropic Claude and OpenAI APIs
- Uses Claude Haiku 4.5 (claude-haiku-4-5-20251001) for cost efficiency ($1/$5 per million tokens)
- Falls back to OpenAI gpt-4o-mini if Anthropic key not available
- Integrates into release workflow between validation and release creation
- Compares current version with previous git tag to generate changelog
- Outputs categorized, user-friendly release notes with installation instructions
Workflow now automatically:
1. Finds previous release tag
2. Analyzes all commits since last release
3. Generates structured release notes via LLM
4. Uses generated notes for draft release body
Requires ANTHROPIC_API_KEY or OPENAI_API_KEY in GitHub secrets.
Related to #671 (automated release workflow)
- Standalone binaries (pulse-sensor-proxy-*, pulse-host-agent-*) were matching both binaries AND .sha256 files
- .sha256 files already uploaded in 'Upload checksums.txt first' step
- gh release upload fails when same asset uploaded twice
- Fix: Use explicit loop to exclude .sha256, .tar.gz, and .zip extensions from standalone binary upload
Error was:
asset under the same name already exists: [pulse-sensor-proxy-linux-386.sha256 ...]
Related to #671 (automated release workflow)
- Reorder jobs: build-docker-images FIRST, then create-release
- Previously: release created first, then Docker builds → if Docker fails, release exists without images
- Now: Docker images built first → if Docker fails, no release created
- Add timeout-minutes: 60 to build-docker-images job
- Add timeout-minutes: 30 to create-release job
- Update release notes template to mention Docker images
- create-release job now depends on build-docker-images success
Related to #671 (automated release workflow)
Addresses Dev Team 1 finding: CRITICAL-3 architectural time bomb
Release workflow now builds and pushes Docker images after creating
the draft release:
- Pulse server image (linux/amd64, linux/arm64)
- Docker agent image (linux/amd64, linux/arm64)
- Pushed to both Docker Hub and GHCR
- Tagged with version and 'latest'
Requires DOCKER_USERNAME and DOCKER_PASSWORD secrets to be configured.
- Add GitHub Actions workflow that validates releases after upload
- Re-downloads all assets from GitHub release
- Re-runs validate-release.sh on downloaded assets
- Sets commit status (blocks publish if validation fails)
- Updates release description with validation results
Final safety net: Catches checksum mismatches even after upload
Related to #671
- Add GitHub Actions workflow for fully automated releases
- Build → validate → create draft → upload assets (checksums.txt first)
- Add --skip-docker flag to validate-release.sh for CI environments
- Workflow ensures checksums.txt cannot drift from binaries
- Manual trigger via workflow_dispatch or automatic on version tags
Eliminates: Manual release process errors, checksum drift issues
Related to #671
Create GitHub Actions workflow that validates release assets AFTER they're uploaded
to catch issues even if someone manually uploads or modifies assets.
Features:
- Triggers on release created/edited (draft only)
- Downloads all assets from GitHub release
- Re-runs scripts/validate-release.sh on downloaded assets
- On validation failure:
* Deletes all assets from the release
* Sets commit status to failed
* Updates release description with error details
- On validation success:
* Sets commit status to success
* Updates release description with validation summary
This acts as a safety gate to prevent publishing releases with:
- Missing required files
- Checksum mismatches
- Incorrect version strings in binaries
- Corrupted or incomplete uploads
This commit introduces a comprehensive GitHub Actions workflow for
creating releases, ensuring all artifacts are validated before upload.
Changes:
- Add .github/workflows/release.yml: Manual workflow_dispatch trigger
that builds, validates, and creates draft releases
- Update scripts/validate-release.sh: Add --skip-docker flag to allow
validation without Docker image checks
Key features:
- Validation runs BEFORE any assets are uploaded
- If validation fails, no release is created
- checksums.txt and artifacts come from the same build
- No manual steps between validation and upload
- Checksums uploaded first, then all other assets
- Creates draft release for manual review before publishing
The workflow ensures that checksums.txt cannot drift from binaries
by running the entire build-validate-upload pipeline atomically.
Add asset availability check before updating demo server. The workflow now waits
up to 5 minutes for checksums.txt and the linux-amd64 tarball to be available
before attempting the update. This prevents the install script from failing when
the release is published before all assets finish uploading.
Resolves demo server downtime during releases.
The publish-helm-chart workflow was failing with 403 errors when attempting
to upload Helm chart assets to GitHub releases. This was caused by the workflow
having only 'contents: read' permission. Changed to 'contents: write' to allow
the 'gh release upload' command to succeed.
The workflow was failing because /api/state requires authentication,
but the verification step was making an unauthenticated request.
Changes:
- Authenticate with demo/demo credentials before checking node count
- Use jq for cleaner JSON parsing instead of grep/cut
- Check total node count from API response instead of regex pattern matching
Related to user report about demo server not updating to 4.26.3.
The demo server was actually updated successfully, but the workflow
marked itself as failed due to the verification check failing.
Removed all legacy Pulse+ agent metrics infrastructure (cloud-relay) which has been
fully replaced by the new docker agent and temperature agent implementations.
Changes:
- Remove cloud-relay directory and all related binaries (relay, relay-linux, etc.)
- Remove Pulse+ documentation (AGENT_METRICS_IMPLEMENTATION.md, AGENT_METRICS_SETUP.md)
- Clean up pulse-relay references in workflows and release checklist
- Add audit log rotation documentation for sensor proxy hash-chained logs
- Update .gitignore to remove cloud-relay/ entry
The new docker and temp agents remain fully functional and unaffected by this cleanup.
