The OMP SDK automation: a hands-off story

Project Discussion Workshop
1

Keeping an SDK on autopilot

Not long ago I slopped out omp as a Workshop SDK.

The upstream omp is vibe-coded at the speed of light, which means there’s continuous new releases (and major version bumps too). I wanted to follow the track naming convention that we’ve been using in our charms in the Observability Team, that is, roughly:

  • git branch track/15 → releases to 15/edge
  • every so often (in my team that’s 2 weeks), we roll the releases up by one risk track (provided some quality gates pass), so edge → beta, beta → candidate, and so on

On top of this, I wanted the process to be fully automated so I can do better things with my time.
Here’s the setup I ended up with.

New major upstream release → new track

omp does semver, and we keep one track/<major> branch per major version (track/17 is current).
bootstrap-major.yml runs on a cron (24h) and whenever upstream cuts a new major, it:

  • diffs the highest major on the SDK’s default branch against the highest major upstream has actually released
  • if upstream is ahead, cuts a new track/N branch, bumps VERSION, and rewrites renovate.json so Renovate only proposes patches within that major going forward
  • creates the store track and opens a PR that auto-merges once the build check passes
  • flips the repo’s default branch to the new track
  • kicks off the first upload

It’s idempotent, and to work only needs a GH PAT with r/w access to this repo.

Every upstream release → new SDK build, rolling down the belt

Ordinary patch and minor releases are handled by Renovate opening a PR against the current
track, and once merged, upload.yml takes over. Three steps:

  1. snapshot: record what revision currently sits in edge/beta/candidate before anything changes, via promote-pipeline.sh
  2. build-and-upload: build all six platform combos (22.04/24.04/26.04 x amd64/arm64) and push the new revision to <track>/edge
  3. promote: if the build succeeded, cascade the previous snapshot one risk level down the belt: candidate becomes stable, beta becomes candidate, edge becomes beta

So a release doesn’t just land in edge and sit there. Every successful build pushes everything already in the pipeline one step closer to stable, which means a build has to survive multiple release cycles at progressively higher risk levels before real users see it.

Where next?

Interested in this workflow? Happy to think about abstracting this to a reusable component that anyone can use to automate the release of new SDKs.

5 Likes