ci: refactor on push and release workflows to use same cached build used in tests #657
Conversation
* ci, tests: pass charm artefacts to deploy and test charms This commit enables the "--charm-path" option to pass .charm artefacts to be deployed and tested at an individual level. This change enables the option to pass pre-built charms to the tests to avoid building them on the same test. It also ensures compatibility with the build_charm.py reusable workflow (from canonical/data-platform-workflows). Fixes: #639
…F-6756-refactor-ci-on-push-release-publish
There was a problem hiding this comment.
Renamed from release.yaml for consistency with data repos
| destination_channel: | ||
| description: CharmHub channel to publish to | ||
| required: false | ||
| default: 'latest/edge' | ||
| type: string |
There was a problem hiding this comment.
Transferred comment from #655 (comment)
is this input ever used? I would imagine you would just dispatch the workflow on the correct branch and then the charming-actions/channel would get the channel right?
@carlcsaposs-canonical we do use this input in workflow dispatch, for example during our beta release we use it to release charms from latest/edge to <version>/beta
There was a problem hiding this comment.
wouldn't promote.yaml be used for beta releases?
There was a problem hiding this comment.
yeah that's true, I think in this case there's no use for workflow_dispatch for this workflow. WDYT?
| # TODO: use canonical/charming-actions/promote-charm? | ||
| uses: canonical/charming-actions/[email protected] |
There was a problem hiding this comment.
Transferred comment from https://github.com/canonical/kfp-operators/pull/655/files#r1920090360
promote-charm looks like a new action that might work better here? not sure
From the README.md it looks like it's similar to release-charm except that it cover multi-base charms. Our team does not support that. I will confirm if that's the only difference.
Based on #655
Closes #650
Closes #656
Summary
This PR refactors the repo's CI to use the same cached builds for individual integration tests, release charm, and promote workflows.
The workflows are refactored to follow the same structure and conventions as in data platform teams. It includes the following changes:
integrate.yamland renames it toci.yamlrelease.yamlwhich reused data platform workflows'release_charm.yamlon_pull_request.yamlandon_push.yamlworkflows, instead they reuse theci.yamlfor tests andrelease.yamlfor releasing to charmhubrelease.yamltopromote.yaml