Tracker for things to improve how we release rocks, integrate them into charms, and release charms

[ca-scribner]

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:

1. in the rock repo, open a PR with the update to main
2. get PR from (1) approved and merged
3. (case depending) backport the update from main to track/VERSION by opening a PR
4. get PR from (3) approved and merged
5. in the charm repo, open a PR to main with the updated image reference
6. get PR from (5) approved and merged, which triggers publishing of the charm to latest/edge
7. (case depending) backport the update from main to track/VERSION by opening a PR
8. get PR from (7) approved and merged, which triggers publishing of the charm to VERSION/edge
9. Test the updated charm from VERSION/edge in the kubeflow bundle(s) that it contributes to
10. 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

1. Have a more efficient, less human-intense release process, ideally that requires only one developer

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-5610.

This message was autogenerated