Removed:
- Individual .sha256 files (checksums.txt already contains all checksums)
- Standalone binaries without version numbers (users should download versioned tarballs/zips)
Standalone binaries are only needed in Docker images for the /download/ endpoint.
GitHub releases should only contain versioned archives for user downloads.
This reduces release assets from ~54 files to ~19 files per release.
The pulse-chart package in GHCR currently requires authentication for pulls
because it defaults to private visibility. This affects all users trying to
install via `helm install oci://ghcr.io/rcourtman/pulse-chart`.
This commit adds a workflow step to automatically set the package to public
after each push, enabling anonymous pulls without requiring `helm registry login`.
Note: The existing package will need one-time manual configuration via GitHub
web UI until the next release triggers this workflow.
Related to discussion #686
Users don't care about CI/CD improvements, release workflows, build
processes, or testing infrastructure. Only include user-visible changes.
Related to #671
Commit hashes clutter the release notes and aren't useful for end users.
Only include issue references when explicitly mentioned in commits.
Related to #671
Remove # symbol from commit hash references so GitHub auto-links them.
Format: (abc123) instead of (#abc123)
Issue references still use #: (#123)
Related to #671
Backticks in GitHub Actions output were still being interpreted even
when assigned to a variable and then echoed to a file. Use heredoc
with single quotes to prevent any bash expansion.
Related to #671
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)
Document the complete automated release process for future reference:
- Step-by-step release workflow trigger
- What each phase does (Docker build, release creation)
- How to review and publish draft releases
- Troubleshooting common issues
- Emergency rollback procedures
- Workflow architecture and design principles
This ensures future AI contexts and maintainers understand the full
release process without needing to reverse-engineer the workflow.
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)
- Use exact template format from v4.28.0 and prior releases
- Include all standard sections: New Features, Bug Fixes, Improvements, Breaking Changes
- Add complete installation instructions (systemd, Docker, Manual Binary, Helm)
- Include Downloads section with all artifact types
- Add Notes section for important highlights and upgrade considerations
- Ensure LLM outputs format exactly matching previous releases
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.
Documents findings from independent reviews by 4 development teams:
- Team 1: Architecture & Security
- Team 2: Artifact Integrity
- Team 3: Update Flow Integration
- Team 4: Post-Merge Validation
All 3 critical blockers have been fixed and pushed to main.
Release process is APPROVED FOR PRODUCTION.
High/medium priority improvements documented for follow-up work.
The script does pushd into RELEASE_DIR, so tarball paths should not include
the RELEASE_DIR prefix. Also fixed checksum validation glob patterns to
exclude .sha256 files from matching.
Tarballs are created with ./bin/pulse paths (relative from inside staging dir)
but validation was looking for bin/pulse paths. Updated all tar -tzf checks
to use correct ./ prefix.
The validation script was looking for tarballs in the current directory
instead of the release/ directory, causing all validations to fail.
Now properly prepends $RELEASE_DIR to all file paths.
- 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
- Add job queue system to ensure only one update runs at a time
- Add Server-Sent Events (SSE) for real-time push updates
- Increase rate limit from 20/min to 60/min for update endpoints
- Add unit tests for queue and SSE functionality
- Frontend: Update modal now uses SSE with polling fallback
Eliminates: 429 rate limit errors, duplicate modals, race conditions
Related to #671
- Add comprehensive Playwright-based integration tests (60+ tests)
- Add mock GitHub release server for controlled testing
- Add 6 test suites: happy path, bad checksums, rate limiting, network failures, stale releases, frontend validation
- Add GitHub Actions workflow for automated testing
- Test infrastructure will catch v4.28.0-style issues automatically
This establishes the testing baseline for all update system changes.
This commit implements a comprehensive refactoring of the update system
to address race conditions, redundant polling, and rate limiting issues.
Backend changes:
- Add job queue system to ensure only ONE update runs at a time
- Implement Server-Sent Events (SSE) for real-time update progress
- Add rate limiting to /api/updates/status (5-second minimum per client)
- Create SSE broadcaster for push-based status updates
- Integrate job queue with update manager for atomic operations
- Add comprehensive unit tests for queue and SSE components
Frontend changes:
- Update UpdateProgressModal to use SSE as primary mechanism
- Implement automatic fallback to polling when SSE unavailable
- Maintain backward compatibility with existing update flow
- Clean up SSE connections on component unmount
API changes:
- Add new endpoint: GET /api/updates/stream (SSE)
- Enhance /api/updates/status with client-based rate limiting
- Return cached status with appropriate headers when rate limited
Benefits:
- Eliminates 429 rate limit errors during updates
- Only one update job can run at a time (prevents race conditions)
- Real-time updates via SSE reduce unnecessary polling
- Graceful degradation to polling when SSE unavailable
- Better resource utilization and reduced server load
Testing:
- All existing tests pass
- New unit tests for queue and SSE functionality
- Integration tests verify complete update flow
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.
This commit addresses three recurring issues with the update system:
1. **Checksum mismatches (v4.27.0, v4.28.0):**
- Root cause: Release process uploads checksums.txt first, but if artifacts
are rebuilt after that upload, checksums become stale
- Fix: Update RELEASE_CHECKLIST.md to REQUIRE running validate-release.sh
before publishing (step 9, non-negotiable)
- The validation script exists and catches these errors, but wasn't being
enforced in the release process
2. **Duplicate error modals:**
- Root cause: UpdateProgressModal rendered in both App.tsx
(GlobalUpdateProgressWatcher) and UpdateBanner.tsx
- Fix: Remove UpdateProgressModal from UpdateBanner.tsx
- GlobalUpdateProgressWatcher automatically shows the modal when updates
start, so the banner's modal is redundant
3. **Rate limiting too strict:**
- Root cause: UpdateProgressModal polls /api/updates/status every 2 seconds
(30 req/min), but rate limit was 20/min
- Fix: Increase UpdateEndpoints rate limit from 20/min to 60/min
- Allows modal to poll without hitting rate limits during updates
These were all manual process errors and configuration issues, not code bugs.
The validation script enforcement prevents future checksum mismatches.
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.
This is the proper architectural fix for #685. The previous commit was a
bandaid that prevented unnecessary .env writes. This commit addresses the
root cause: dual-source-of-truth for API tokens (.env vs api_tokens.json).
Changes:
1. Startup Migration (config.go:896-951):
- When loading config, if API_TOKEN/API_TOKENS exist in .env but not in
api_tokens.json, automatically migrate them
- Migrated tokens are named "Migrated from .env (prefix)" for clarity
- Logs a deprecation warning: API_TOKEN/API_TOKENS in .env are deprecated
- Leaves .env untouched (safe for existing deployments)
2. Config Watcher Changes (watcher.go:338-424):
- Only load tokens from .env if api_tokens.json is EMPTY
- Once api_tokens.json has records, it becomes the authoritative source
- .env changes no longer trigger token overwrites when api_tokens.json exists
- Logs debug message when ignoring env tokens
Result:
- Existing deployments: env tokens automatically migrated to api_tokens.json
- UI-created tokens: never overwritten by .env changes
- Dark mode toggle: no longer triggers token reload from .env
- Backward compatible: fresh installs with API_TOKEN in .env still work
- Migration path: users can safely keep API_TOKEN in .env, it will be ignored
Future improvement: Add UI warning when API_TOKEN/API_TOKENS still present
in .env, prompting users to rotate tokens via the UI.
Root cause: SaveSystemSettings calls updateEnvFile which rewrites .env on
any setting change, triggering the config watcher. The watcher sees API_TOKEN
in .env and replaces all UI-created tokens with "Environment token" records,
wiping out host-agent scoped tokens.
Fix: updateEnvFile now compares the new content with existing content and
skips the write if nothing changed. Since dark mode (and other UI settings)
are stored in system.json, not .env, toggling theme no longer triggers
unnecessary .env rewrites.
This prevents the config watcher from being triggered unnecessarily and
preserves UI-created API tokens when changing cosmetic settings.
Future improvement: Deprecate API_TOKEN/API_TOKENS from .env entirely and
make api_tokens.json the single source of truth (requires migration logic).
When disabling offline alerts for VMs/containers, the setting was being persisted
correctly and honored by the alert system, but the UI always showed "Warn" instead
of the actual saved state.
Root cause: When reconstructing the overrides list from backend config, the guest
override mapping was copying poweredOffSeverity but omitting disableConnectivity,
causing ResourceTable to fall back to global defaults.
Fix: Add disableConnectivity field to guest override reconstruction in Alerts.tsx
(line 676), matching the pattern already used for Docker containers.
Users were confused about how to access the bootstrap token in Proxmox
LXC containers. They were trying to use the Proxmox web console instead
of 'pct enter' from the Proxmox host.
This adds explicit instructions in the FirstRunSetup UI that show:
- pct enter <ctid> for interactive access
- pct exec <ctid> -- cat /etc/pulse/.bootstrap_token for direct retrieval
- Clear indication that commands should be run from Proxmox host
The instructions only display when the deployment is not Docker and the
bootstrap token path is /etc/pulse/.bootstrap_token (indicating LXC).
Fixes#681
Related to #681
The variable local_proxy_binary was declared with local scope inside
the BUILD_FROM_SOURCE conditional block but referenced outside of it
during cleanup. This caused "unbound variable" errors on release installs
since the script uses set -u.
Moved the declaration before the conditional block and initialize to empty
string. The cleanup code [[ -f "$local_proxy_binary" ]] already handles
the empty string case safely.
Updated FirstRunSetup to show generic container commands that work
across different orchestration platforms:
- Use <container-name> placeholder instead of hardcoded "pulse"
- Add kubectl exec example for Kubernetes/Helm deployments
- Clarify "From container host" applies to Docker, Podman, etc.
This ensures the instructions work for Docker Compose, Swarm, Helm,
and any other container orchestrator where the container might have
a different name.
The bootstrap-token CLI command had two bugs:
1. Used PULSE_DATA_PATH instead of PULSE_DATA_DIR (typo)
2. Used /var/lib/pulse as fallback instead of /etc/pulse
This caused the command to look in the wrong location for non-Docker
deployments. Fixed to match config.Load() logic:
- Check PULSE_DATA_DIR env var first
- Fall back to /data for Docker, /etc/pulse otherwise
The first-run setup UI was displaying incorrect bootstrap token paths for
Docker deployments. It showed `/etc/pulse/.bootstrap_token` regardless of
deployment type, but Docker containers use `/data/.bootstrap_token` by
default (via PULSE_DATA_DIR env var).
Changes:
- Extended `/api/security/status` endpoint to include `bootstrapTokenPath`
and `isDocker` fields when a bootstrap token is active
- Updated FirstRunSetup component to fetch and display the correct path
dynamically based on actual deployment configuration
- For Docker deployments, UI now shows both `docker exec` command and
in-container command
- Falls back to showing both standard and Docker paths if API data
unavailable (backward compatibility)
This fix ensures users always see the correct command for their specific
deployment, including custom PULSE_DATA_DIR configurations.
