Skip to content

Comments

ci: release packed charm to PR-specific Charmhub track (best-effort)#401

Draft
sed-i wants to merge 2 commits intomainfrom
feat/pr-charmhub-upload
Draft

ci: release packed charm to PR-specific Charmhub track (best-effort)#401
sed-i wants to merge 2 commits intomainfrom
feat/pr-charmhub-upload

Conversation

@sed-i
Copy link
Contributor

@sed-i sed-i commented Oct 24, 2025

Note: The first commit in this PR was prepared using copilot.

This change adds a best-effort step to the pack-charm job that uploads/releases the packed charm to a PR-specific Charmhub track pr/edge/<PR_NUMBER>. The step uses the CHARMHUB_TOKEN and is marked continue-on-error so failures won't block the workflow.

Fixes #400.

@sed-i sed-i requested a review from a team as a code owner October 24, 2025 04:04
Signed-off-by: Leon <82407168+sed-i@users.noreply.github.com>
@lucabello lucabello marked this pull request as draft October 24, 2025 07:30
uvx --quiet --from git+https://github.com/lucabello/noctua noctua charm release \
"$CHARM_NAME" \
--path "$path" \
--channel "pr/edge/${{ github.event.pull_request.number }}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Track should be dev/edge/<branch> probably

@lucabello
Copy link
Contributor

Also note that this should be at the very least optional, but might also warrant a new CI major version if we decide to go for it - in which case I'd have lots of adjustments I'd like to make to workflows in general

Let's discuss it in the lead sync!

@lucabello
Copy link
Contributor

Thinking about this a bit more; introducing this change would require a PR in all charms to explicitly enable it. We could bundle this in a new v2 for our CI, but there's another set of changes I would like to bundle there, and it would surely delay things.


One more problem about this is that the automation would require one specific track where these charm revisions are released to. Using a new pr track on all of our charms is confusing in my opinion - we already have dev. A problem that applies to both though is that PRs are not necessarily targeted towards main:

  • if the PR targets main, maybe we release to dev/edge/pr123
  • what if the PR targets track/2? we should release to 2/edge/pr123
  • what if the PR targets another branch (which is the one that will end up merging to main)?

Maybe if we look a bit more at the problem: do we actually need every PR commit of every charm to be uploaded to Charmhub? My understanding is that this applies when we want someone to try out a fix before we merge it. This shouldn't necessarily be our default behavior, as it encourages not writing tests in favor of verifying the correct behavior manually.

As a reminder, there's already a one-liner to do this:

∮ noctua charm release <charm-name> --channel=<ephemeral-branch> --path <path-to-.charm>
∮ noctua charm release prometheus-k8s --channel=dev/edge/pr123 --path=./prometheus-k8s_ubuntu@24.04-amd64.charm

Considering the low barrier to do this manually, the complications around automating this, and the fact that this problem happens infrequently, maybe it's not worth implementing this in CI right now.

If you feel strongly about it though, we can discuss :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

On PR, release charm to temporary branch pr/edge/N

2 participants