Skip to content

Conversation

@chocobar
Copy link
Collaborator

Summary

This PR integrates Wolf releases with the Helix release process for synchronized versioning and automated builds.

Key Changes

1. Unified Versioning

  • Wolf versions now match Helix versions (e.g., when Helix releases v1.5.0, Wolf also gets v1.5.0)
  • Production: docker-compose.yaml uses HELIX_VERSION for Wolf
  • Development: docker-compose.dev.yaml uses latest from Helix registry

2. Automated Wolf Releases via Helix CI

  • Added build-wolf pipeline to Helix Drone CI
  • When you tag a Helix release, Drone automatically:
    1. Clones Wolf from stable branch
    2. Tags Wolf with the Helix version
    3. Builds Wolf Docker image
    4. Publishes to registry.helixml.tech/helix/wolf:v1.5.0

3. Simplified Local Development

  • ./stack rebuild-wolf with HELIX_VERSION set: pulls from registry
  • ./stack rebuild-wolf without HELIX_VERSION: builds from local source
  • No registry push from local builds (releases handled by CI)

Benefits

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

  • Local Wolf builds tested
  • Drone CI pipeline syntax validated
  • Environment variable logic verified

Requirements

  • Requires github_ssh_key secret in Drone with write access to helixml/wolf repo

🤖 Generated with Claude Code

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.
@chocobar chocobar force-pushed the build-release-improvs branch from 11a7e7c to 1b63541 Compare November 19, 2025 12:27
@lukemarsden lukemarsden marked this pull request as draft November 21, 2025 05:48
@lukemarsden
Copy link
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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants