Enable build charm(s) with cache and reusable charm files to speed up CI runs

[DnPlas]

Enhancement Proposal

One of the biggest bottlenecks of charm development is building charm sin the CI: it takes forever, and it only gets worse as the list of charms to build grows. The data-platform-workflows (by @carlcsaposs-canonical) repository contains a series of GH actions that can be leveraged for building the charms with a cache and reuse them across different jobs in a workflow.

The most obvious example where this is useful is the publish job, which also packs the charm(s) in the repo on the same CI where other jobs are running, but there could be other actions that may be benefited from this.

For more information, go here

[carlcsaposs-canonical]

FYI a release_charm.yaml workflow exists as a replacement for charming-actions/upload-charm (and the workflow fixes a design bug in the action that causes issues when uploading resources for the first time)

---

I don't think it's possible for charming-actions to use data-platform-workflows since reusable workflows are used at the job level, but github actions are used at the step level

But I think it could be worth migrating some of the existing charming-actions to workflows, since at least for us, we've found python+yaml easier to maintain than javascript actions

[DnPlas]

I don't think it's possible for charming-actions to use data-platform-workflows since reusable workflows are used at the job level, but github actions are used at the step level

I wonder if we can convert it into an action instead (we could even explore an action with python code), I think a lot of projects would be benefited, though that potentially means changing certain things in the workflow.

[carlcsaposs-canonical]

From my understanding, only JavaScript and Docker actions are supported by GitHub

I think a lot of projects would be benefited

Do you have examples of use cases for data-platform-workflows where an action would be preferred over a workflow? I'm struggling to understand