When creating data-platform-workflows for our team’s repositories, we made a few decisions to simplify the workflows that limit the reusability for some configurations (e.g. repos with more than one charm, private repos). As we look to share these workflows more broadly with the charming community, it’s worth revisiting these limitations (and also improving the documentation). At the same time, supporting more configurations/addressing these limitations will require significant development work and I’m not sure how many resources we have for that work.
- This might change in the future, as our team has discussed the possibility of having some repos with more than one charm—but no decisions have been made about that yet.
To my knowledge, the only workflow that doesn’t work well for repos with more than one charm is release_charm.yaml, when called with create-github-release: true (the default). However, the workflows are currently only used/tested on repos with one charm.
- Unfortunately, this is mostly a limitation of GitHub: https://github.com/actions/toolkit/issues/1264. We made a decision to move a lot of the workflow logic to Python scripts to improve maintainability & reusability between workflows. However, this requires us to know the version of the workflow that’s running.
We found two possible solutions: (a) checking out the public caller repo or (b) specifying the workflow version twice when calling it—(b) would work for private repos, but it would cause issues if it gets out of sync with the other version. It’s possible to fork data-platform-workflows, and replace _get_workflow_version.yaml with a workflow input with the version. We might consider taking this approach in the future (or having it as a configurable option), but it would require some development work to create & maintain.
It may be possible to workaround this with the current workflows by setting the GITHUB_TOKEN to a personal access token or app token that has access to your repositories, but I’m not sure.
-
This might be helpful: https://github.com/canonical/charming-actions/blob/main/release-libraries/README.md (this is a javascript github action, different from the python/yaml github workflows in data-platform-workflows)
-
I have no experience with this—perhaps someone with more experience with Launchpad might be able to help.
Hope this helps give you some context & provide some possible options for ways to workaround the limitations we currently have.
Thank you for trying out the reusable workflows! The issues you’re running into with the workflows now are likely issues we’ll run into in the future—and learning/improving the workflows from your use case is also valuable to us.
