Upgrade Concourse CI

Change Concourse CI version (upgrade or downgrade)

Upgrade to Newer Version

# Set new version
juju config concourse-ci version=7.14.3

# Monitor upgrade progress
juju status --watch 1s

What happens:

✅ Automatic worker upgrades: Workers automatically upgrade when they detect the web server is running a different version. No manual intervention needed!

Downgrade to Older Version

# Set older version
juju config concourse-ci version=7.12.1

# Workers will automatically downgrade to match

⚠️ Database migrations: Downgrading may fail if the database schema changed between versions. Test in non-production first.

Upgrade from Latest (Auto-Detect)

When version is set to latest (default), the charm auto-detects the latest release from GitHub:

# Check current version
juju config concourse-ci version

# Force refresh to latest (if version=latest)
juju config concourse-ci version=latest

Check Current Version

# Via juju status
juju status concourse-ci
# Look for version in status message: "Web ready (v7.14.2)"

# Via configuration
juju config concourse-ci version

# Via Concourse CI web UI
# Open http://<web-ip>:<port> and check footer

Distributed Mode (Separate Web/Worker Apps)

For distributed deployments, upgrade web first, then workers follow automatically:

# Upgrade web application
juju config web version=7.14.3

# Workers automatically upgrade via TSA relation
# Check worker status
juju status worker
# Should show: "Auto-upgrading Concourse CI to 7.14.3..."

Monitor Upgrade Progress

# Watch status updates
juju status --watch 1s

# Check logs
juju debug-log --include concourse-ci --tail

# For specific unit
juju debug-log --include concourse-ci/0 --replay --no-tail

Status messages during upgrade:

Upgrading to v7.14.3... - Download and installation in progress
Auto-upgrading Concourse CI to 7.14.3... - Worker detected version mismatch
Web ready (v7.14.3) - Upgrade complete

Rollback After Failed Upgrade

# If upgrade fails, revert to previous version
juju config concourse-ci version=7.12.1

# Check logs for failure reason
juju debug-log --include concourse-ci --replay | grep -i error

Shared Storage Mode Benefits

When using shared storage, upgrades are significantly faster:

Without shared storage: Each worker downloads ~90MB binary
With shared storage: Binary downloaded once, shared across all workers
Speed improvement: ~63% faster upgrades (measured with 3 workers)

Verify Upgrade Success

# 1. Check all units are active
juju status concourse-ci

# 2. Verify web version
curl -s http://<web-ip>:8080/api/v1/info | jq .version

# 3. Check workers via Fly CLI
juju ssh concourse-ci/0
fly -t local workers
# All workers should show same version

# 4. Run a test pipeline
fly -t local execute -c test.yml

💡 Best practice: Always test upgrades in a staging environment before applying to production.

Related Actions

Set Up Shared Storage - Speed up upgrades by 63%
Troubleshooting - Fix common upgrade issues
Configuration Reference - All available options