/release -- Create a Release
Trigger
User asks to release, deploy, bump the version, or trigger a deployment.
Workflow
- •
Understand the release mechanism:
- •CI deploys are triggered by changes to
ansible/inventories/default/group_vars/all/version.yamlonmain - •The
version.yamlfile contains version references used by Ansible playbooks - •Pushing a change to this file on
maintriggers the GitHub Actions deploy workflow
- •CI deploys are triggered by changes to
- •
Determine what to bump. Key version fields in
version.yaml:- •
phylum_version(set viaapp_version) - •
substrate_chaincode_version(set viasubstrate_version) - •Related client/gateway versions
The actual version values come from
env.yamlvariables (app_version,substrate_version). Check both files:bashcat ansible/inventories/default/group_vars/all/version.yaml cat ansible/inventories/default/group_vars/all/env.yaml
- •
- •
Create the version change:
- •Create a feature branch if not already on one
- •Update the version values in
env.yamlorversion.yamlas appropriate - •Chain to
/verifyto validate
- •
Create a PR -- chain to
/pr:- •Title: "Release: bump <component> to <version>"
- •The PR body should clearly state what version is being deployed
- •
After the PR is merged to
main, the CI pipeline will:- •Detect the
version.yamlchange - •Run
run-ansible.shwithapp.yaml - •Deploy to the configured environment
- •Detect the
- •
Monitor the deployment:
bashgh run list --workflow=deploy.yml --limit 5 gh run watch <run-id>
Anti-patterns
- •Do not push version changes directly to
main-- always use a PR - •Do not bump versions without understanding what will be deployed
- •Do not skip monitoring the deployment after merge
- •Do not modify
version.yamlfor non-deployment purposes (it triggers CI)
Checklist
- • Current versions reviewed
- • Version bump identified and applied
- • Changes verified (
/verify) - • PR created with clear release description (
/pr) - • Deployment monitored after merge