This issue describes some friction in our rock/charm release process, and is a tracker issue to collect efforts to improve this situation.
Presently, the process integrating a rock update into Charmed Kubeflow has many manual steps:
in the rock repo, open a PR with the update to main
get PR from (1) approved and merged
(case depending) backport the update from main to track/VERSION by opening a PR
get PR from (3) approved and merged
in the charm repo, open a PR to main with the updated image reference
get PR from (5) approved and merged, which triggers publishing of the charm to latest/edge
(case depending) backport the update from main to track/VERSION by opening a PR
get PR from (7) approved and merged, which triggers publishing of the charm to VERSION/edge
Test the updated charm from VERSION/edge in the kubeflow bundle(s) that it contributes to
If (9) passes, promote the charm from VERSION/edge to VERSION/beta,candidate,stable via gh action
This includes:
4 PRs
4 approvals
1 manually triggered workflow
some minor copying/pasting
Step (1) is the only place where engineering work happens (unless there's a test failure in steps 2-10). Absent a test failure, steps 2-10 are entirely deterministic steps that have room for human error (copying the wrong image name, forgetting to push to a track/promote to a risk, etc) and take time.
The above process happens frequently, for example :
all charms need this at least once per rock per release, although some of these can be batched together
a subset of charms need this during any upstream patch release (eg: 1.8.1)
any security patch fix on an image needs this
any bug fix on a charm or image (at least some of) this
Tracked issues:
(none yet)
What needs to get done
Given how frequently we do this, we should streamline the above process. This could be through automation, for example:
open a PR against a charm when a rock gets updated
automate backports
add some chatops style automation for promoting charms from edge to stable
Some benefits of automation would include reducing the number of PRs a human must create and also removing the need for independent review (if a human creates a PR we need a second human to review/approve it. if automation creates the PR, we need a single human to review/approve it).
Definition of Done
Have a more efficient, less human-intense release process, ideally that requires only one developer
Context
This issue describes some friction in our rock/charm release process, and is a tracker issue to collect efforts to improve this situation.
Presently, the process integrating a rock update into Charmed Kubeflow has many manual steps:
main
main
totrack/VERSION
by opening a PRmain
with the updated image referencelatest/edge
main
totrack/VERSION
by opening a PRVERSION/edge
VERSION/edge
in the kubeflow bundle(s) that it contributes toVERSION/edge
toVERSION/beta,candidate,stable
via gh actionThis includes:
Step (1) is the only place where engineering work happens (unless there's a test failure in steps 2-10). Absent a test failure, steps 2-10 are entirely deterministic steps that have room for human error (copying the wrong image name, forgetting to push to a track/promote to a risk, etc) and take time.
The above process happens frequently, for example :
Tracked issues:
What needs to get done
Given how frequently we do this, we should streamline the above process. This could be through automation, for example:
Some benefits of automation would include reducing the number of PRs a human must create and also removing the need for independent review (if a human creates a PR we need a second human to review/approve it. if automation creates the PR, we need a single human to review/approve it).
Definition of Done