You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For rocks we produce, we use the tagging scheme<upstream-version>-<commit>, where the commit is the implicit version for our rock (eg: if we edit the rock built for a given upstream version). For charm repositories that use these rocks, this can make it tough to know if the charm repo is using the "correct" image (likely, the most up to date image for that release track). We should implement some automation to make this clearer.
This would also be helpful for reviewing PRs. We could implement CI similar to the charm library checks that warn on a PR if an image is out of date. This shouldn't block the PR (in case the old image is intentional), but it would be a helpful check. For similar reasons, we could make general maintenance of our charm easier by adding periodic CI that checks if rocks are up to date for a charm, possibly even opening a PR for bumping the image automatically.
Some complications to consider:
because our gh repos house multiple rocks, the "correct" image might not have the most recent commit ID
different charm releases (eg: track/1.1 and track/1.2 of a given charm) will often follow different rock releases (eg: charm 1.2 needs the rock for 1.2), so however we implement this we need to be able to differentiate the tracked image per charm track
What needs to get done
TBD - needs to be decided during initial work
Definition of Done
TBD - needs to be decided during initial work
The text was updated successfully, but these errors were encountered:
Context
For rocks we produce, we use the tagging scheme
<upstream-version>-<commit>
, where thecommit
is the implicit version for our rock (eg: if we edit the rock built for a given upstream version). For charm repositories that use these rocks, this can make it tough to know if the charm repo is using the "correct" image (likely, the most up to date image for that release track). We should implement some automation to make this clearer.This would also be helpful for reviewing PRs. We could implement CI similar to the charm library checks that warn on a PR if an image is out of date. This shouldn't block the PR (in case the old image is intentional), but it would be a helpful check. For similar reasons, we could make general maintenance of our charm easier by adding periodic CI that checks if rocks are up to date for a charm, possibly even opening a PR for bumping the image automatically.
Some complications to consider:
track/1.1
andtrack/1.2
of a given charm) will often follow different rock releases (eg: charm1.2
needs the rock for1.2
), so however we implement this we need to be able to differentiate the tracked image per charm trackWhat needs to get done
TBD - needs to be decided during initial work
Definition of Done
TBD - needs to be decided during initial work
The text was updated successfully, but these errors were encountered: