-
Notifications
You must be signed in to change notification settings - Fork 60
Integrate Wolf releases with Helix versioning #1367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
chocobar
wants to merge
9
commits into
main
Choose a base branch
from
build-release-improvs
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
+80
−35
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Change Wolf image tag from HELIX_VERSION to WOLF_VERSION to allow independent versioning of Wolf releases. Usage: export WOLF_VERSION=v1.0.1-rc8 ./stack up Defaults to 'latest' if WOLF_VERSION is not set.
- Modified rebuild-wolf function to check for WOLF_VERSION env var
- If WOLF_VERSION is set, pulls from registry.helixml.tech/helix/wolf:{VERSION}
- Falls back to local source build if WOLF_VERSION is not set
- Maintains backward compatibility with existing local development workflow
Usage:
# Use versioned registry image (recommended for production)
export WOLF_VERSION=v1.0.0
./stack rebuild-wolf
# Build from local source (development)
./stack rebuild-wolf
This integrates with the Wolf Drone CI pipeline for automated versioned releases.
- Wolf versions now match Helix versions for consistency - Production: docker-compose.yaml uses HELIX_VERSION for Wolf - Development: docker-compose.dev.yaml uses latest Wolf from registry - Stack script: rebuild-wolf uses HELIX_VERSION instead of WOLF_VERSION - Drone CI: Added build-wolf pipeline that triggers on Helix tag events When you tag a Helix release (e.g., v1.5.0), Drone will now automatically: 1. Clone the helixml/wolf repository 2. Build Wolf Docker image 3. Push to registry.helixml.tech/helix/wolf:v1.5.0 4. Also tag as 'latest' This ensures Wolf images are always available for each Helix release. Usage: # Production deployment export HELIX_VERSION=v1.5.0 docker compose up -d # Development with versioned Wolf export HELIX_VERSION=v1.5.0 ./stack rebuild-wolf # Development with local Wolf build ./stack rebuild-wolf # No HELIX_VERSION set
When you tag a Helix release (e.g., v1.5.0), the Drone pipeline now: 1. Clones Wolf repo from stable branch 2. Tags the current stable branch with the Helix version tag 3. Pushes the tag to helixml/wolf repo 4. Builds and publishes Wolf with that tag This ensures: - Wolf versions are synchronized with Helix versions - The exact Wolf commit is tagged and traceable - Future builds can reference the specific tagged version Note: Requires 'github_ssh_key' secret configured in Drone with write access to helixml/wolf repository.
Local Wolf builds via './stack rebuild-wolf' now only build locally: - Removed git tag detection and registry tagging logic - Removed PUSH_TO_REGISTRY conditional logic - Simplified build to single 'wolf:helix-fixed' tag Registry releases are now exclusively handled by: - Helix Drone CI when tagging Helix releases - This ensures consistent, automated versioning
The dev compose file now properly uses HELIX_VERSION:
- If HELIX_VERSION is set: uses registry.helixml.tech/helix/wolf:${HELIX_VERSION}
- If HELIX_VERSION is not set: uses wolf:helix-fixed (local build)
This matches the behavior of ./stack rebuild-wolf and ensures
consistent Wolf versioning across development and production.
Development workflow now uses WOLF_LOCAL_BUILD environment variable: **Default (no WOLF_LOCAL_BUILD):** - docker-compose.dev.yaml: uses registry.helixml.tech/helix/wolf:latest - ./stack rebuild-wolf: does nothing (informs user that compose will pull latest) **Local build (WOLF_LOCAL_BUILD=true):** - docker-compose.dev.yaml: uses wolf:helix-fixed - ./stack rebuild-wolf: builds from local Wolf source **Production (docker-compose.yaml):** - Uses HELIX_VERSION if set (e.g., v1.5.0) - Falls back to latest if not set This simplifies development by defaulting to latest registry builds. Docker compose automatically pulls images, so rebuild-wolf only needs to run when building from local source.
Production docker-compose.yaml now always uses: registry.helixml.tech/helix/wolf:latest Removed HELIX_VERSION variable - production deployments will automatically get the latest Wolf image built by Helix CI. When Helix is tagged and released, the Drone CI pipeline automatically builds and pushes Wolf with both the version tag and 'latest', ensuring production always has the most recent stable Wolf build.
…BUILD Simplified rebuild-wolf logic: - Always builds Wolf from ../wolf source - Passes WOLF_LOCAL_BUILD=true directly to docker-compose commands - No environment variable export needed Workflow: 1. ./stack rebuild-wolf # Builds wolf:helix-fixed, starts with WOLF_LOCAL_BUILD=true 2. To continue using local build: WOLF_LOCAL_BUILD=true docker compose up -d 3. To use latest from registry: docker compose up -d (without WOLF_LOCAL_BUILD) Users can also add WOLF_LOCAL_BUILD=true to .env file for persistent local builds.
11a7e7c to
1b63541
Compare
Collaborator
|
did we decide not to land this right now? Converted to draft, because I think that's what you said |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR integrates Wolf releases with the Helix release process for synchronized versioning and automated builds.
Key Changes
1. Unified Versioning
docker-compose.yamlusesHELIX_VERSIONfor Wolfdocker-compose.dev.yamluseslatestfrom Helix registry2. Automated Wolf Releases via Helix CI
build-wolfpipeline to Helix Drone CIstablebranchregistry.helixml.tech/helix/wolf:v1.5.03. Simplified Local Development
./stack rebuild-wolfwithHELIX_VERSIONset: pulls from registry./stack rebuild-wolfwithoutHELIX_VERSION: builds from local sourceBenefits
✅ Synchronized Releases: Single release process for all Helix components
✅ Automated Tagging: No manual Wolf versioning needed
✅ Deterministic Builds: Wolf stable branch is tagged with each Helix release
✅ Simplified Workflow: One tag triggers all builds
Testing
Requirements
github_ssh_keysecret in Drone with write access to helixml/wolf repo🤖 Generated with Claude Code