Releasing Ascender with a script

blaipr

I have come to realize how hard it is to cut a new Ascender release. It is nine or ten repositories, and no two of them release the same way: one wants a tag, one wants a published release, one wants a created release, two want a workflow dispatch that builds images and then leaves a draft behind.

Doing all that by hand, in the right order, every time, is a massive chore, and sometimes one gets left behind. It is completely understandable. I would like to help you automate it somehow, so here is a little script I put together. Hope it helps. One command, all of them get a bump together:

./release-ascender.sh 25.7.0

The script

Save it as release-ascender.sh, make it executable, and run it with the version. It needs gh logged in with write access to ctrliq and nothing else. Anything already carrying the tag is skipped, so it is safe to run again if a step fails. The exception is ascender-ledger, which leaves no tag to check and so fires every run.

#!/usr/bin/env bash
# Release every Ascender repository at one version.
#
#   ./release-ascender.sh 25.7.0
#
# Requires gh, authenticated with write access to ctrliq.

set -euo pipefail

V="${1:-}"
[[ "$V" =~ ^[0-9]{2}\.[0-9]+\.[0-9]+$ ]] || {
  echo "usage: $0 <version>   e.g. 25.7.0   (no v prefix, these repos do not use one)" >&2
  exit 1
}

tagged(){ gh api "repos/ctrliq/$1/git/refs/tags/$V" >/dev/null 2>&1; }

# Tag and release. Each of these does its own thing off the back of it: ascender-kit
# publishes to PyPI on the tag, ascender-collection to Galaxy on the release,
# ascender-ee builds its image, the installers just carry the tag.
for r in ascender-kit ascender-collection ascender-ee \
         ascender-install ascender-k8s-install ascender-pro-install ascender-playbooks; do
  if tagged "$r"; then
    echo "$r: already at $V"
  else
    gh release create "$V" --repo "ctrliq/$r" --title "$V" --generate-notes >/dev/null
    echo "$r: released"
  fi
done

# ascender and ascender-operator build images first and leave a draft release behind.
# Guarded the same way, so a re-run does not kick off a second set of image builds.
if tagged ascender; then
  echo "ascender: already at $V"
else
  gh workflow run stage.yml --repo ctrliq/ascender --ref main \
    -f version="$V" -f confirm=yes
  echo "ascender: staging"
fi

if tagged ascender-operator; then
  echo "ascender-operator: already at $V"
else
  gh workflow run stage.yml --repo ctrliq/ascender-operator --ref devel \
    -f version="$V" -f default_awx_version="$V" -f confirm=yes
  echo "ascender-operator: staging"
fi

# ascender-ledger has no tag, the workflow is the whole release, so there is nothing
# to check it against: this one fires on every run.
gh workflow run release.yml --repo ctrliq/ascender-ledger --ref main \
  -f version="$V" -f confirm=yes
echo "ascender-ledger: dispatched (fires every run, it leaves no tag to check)"

cat <<MSG

When the image builds finish, publish the two drafts to fire promote:
  gh release edit $V --repo ctrliq/ascender --draft=false
  gh release edit $V --repo ctrliq/ascender-operator --draft=false

Where everything stands (ascender and ascender-operator show the old version
until their image builds finish):
MSG

# ascender-galaxy-proxy is not here on purpose: it runs its own 1.x line rather than
# the calendar version, so it is released separately.
for r in ascender ascender-collection ascender-ee ascender-kit ascender-operator \
         ascender-install ascender-k8s-install ascender-pro-install ascender-playbooks; do
  # Filter to NN.N.N: the tag list comes back unordered, and ascender-operator
  # carries a stray "test-restricted" that would otherwise show as the latest.
  printf '  %-22s %s\n' "$r" "$(gh api "repos/ctrliq/$r/tags?per_page=100" \
    --jq '[.[].name|select(test("^[0-9]+\\.[0-9]+\\.[0-9]+$"))]|sort_by(split(".")|map(tonumber))|last // "none"' 2>/dev/null)"
done

What it leaves for you

The version pins still need raising before you run it, the same as today:

ascender-collection: galaxy.yml, and _COLLECTION_VERSION in controller_api.py
ascender-ee: the ctrliq.ascender version in execution-environment.yml
ascender-install, ascender-pro-install: ctrliq.ascender in collections/requirements.yml
the same two: ASCENDER_VERSION and ASCENDER_OPERATOR_VERSION in default.config.yml
ascender, ascender-operator, ascender-kit: nothing, the version comes from the git tag

ascender and ascender-operator stop at a draft, and publishing it is what fires promote.

So the script leaves these two to you, and you can check the images first:

gh release edit 25.7.0 --repo ctrliq/ascender --draft=false
gh release edit 25.7.0 --repo ctrliq/ascender-operator --draft=false

Happy to adjust if I have misread anything, or add a repo I missed.

cigamit

Ya, I have a whole document that has all the steps laid out across all the repos, and I still miss one occasionally. Like I forgot to change _COLLECTION_VERSION this time around. A lot of it is also waiting around for different workflows to finish before moving onto the next piece (ex: collection has to be uploaded before EE can be built)

Thanks for the script, I was planning on writing one myself but just hadn't gotten to it yet.

blaipr

Happy to help! I can't test it, but it should work fine

Let me know if you use it on the next release 😄

blaipr

@cigamit one more thought: we could standardise every repo on one trigger, release: published. Most are nearly there, ascender-collection uses it today and ascender-ee is a one word change from created.

The gain is that every repo then leaves the same artifact behind. ascender-ledger and ascender-playbooks have no tags at all today, so there is no way to ask what version they are on.

ascender and ascender-operator are the only real work, and their build then promote gate can stay, as one workflow on publish with the promote job in a protected Environment. Happy to dig into it if you think it is worth doing.