Reusable Github Actions


Ewoud Kohl van Wijngaarden
 

Hello everyone,

Someone linked this Reusable Github Actions document[1] which is apparently a new beta feature. This is a highly desired feature since it allows removing a LOT of duplication across our modules.

I've said this before, but I'll repeat it here. modulesync is an anti-pattern. Having templates applied on common files is a necessary evil but we should minimize it. This makes that possible. I'd say that today a significant number of changes happen in those files.

So I started gha-puppet[2] and opened a PR[3] to use it. At least initially it looks good.

Right now there's still some TODOs:

* Handle repositories without acceptance tests

Right now we have an ERB template that looks at a file pattern[4]. This needs some other solution. I'm not expecting large difficulties but it's important to not waste CI minutes.

Another way could be to have a separate file for actions including Beaker and excluding. Perhaps someone could also write a version for Litmus that way.

* Handle beaker facts & excludes

Using ERB we have the option to expand the matrix with additional facts[5]. A common use case is to duplicate the entire matrix for My Software v1 and then another for v2. Other examples I have thought about were multiple beaker suites. Right now this sees little use so it's less important. Perhaps it can be solved via inputs but I haven't tried yet. It would be good if we can generate a nice name for that.

The same goes for excludes.

* Release work

We also have a release workflow but I haven't started with that.

I'm sending this email for visibility. I'll also note that right now I have little time to work on this. However, I'd like to start the discussion. Perhaps this is even something Puppet itself might want to host, if we can unify workflows.

[1]: https://docs.github.com/en/actions/learn-github-actions/reusing-workflows
[2]: https://github.com/ekohl/gha-puppet
[3]: https://github.com/voxpupuli/puppet-example/pull/15
[4]: https://github.com/voxpupuli/modulesync_config/blob/a7c683a828332429852a6521598c7ce8652f016a/moduleroot/.github/workflows/ci.yml.erb#L59
[5]: https://github.com/voxpupuli/modulesync_config/blob/a7c683a828332429852a6521598c7ce8652f016a/moduleroot/.github/workflows/ci.yml.erb#L70-L89


 

Hi people,

We discussed that on IRC but I think it's good to point it out here as well. For our puppet-lint plugins we've a modulesync_config setup as well: https://github.com/voxpupuli/puppet-lint_modulesync_configs/tree/master/moduleroot/.github/workflows

It provides a templated GitHub Action for CI and gem release. We don't have a consistent setup for other gems and I don't want to start a third modulesync_config repo for gems. so besides reducing the size of modulesync_config for actual puppet modules, this feature has the huge benefit to cleanup and unify the actions on all gems.

On 10.11.21 17:43, Ewoud Kohl van Wijngaarden wrote:
Hello everyone,
Someone linked this Reusable Github Actions document[1] which is apparently a new beta feature. This is a highly desired feature since it allows removing a LOT of duplication across our modules.
I've said this before, but I'll repeat it here. modulesync is an anti-pattern. Having templates applied on common files is a necessary evil but we should minimize it. This makes that possible. I'd say that today a significant number of changes happen in those files.
I 100% agree. The amount of files in modulesync_config should be reduced as much as possible.

So I started gha-puppet[2] and opened a PR[3] to use it. At least initially it looks good.
Right now there's still some TODOs:
* Handle repositories without acceptance tests
Maybe we can also add more acceptance tests. I did a very naive calculation and from the 152 repos I've cloned locally 105 have acceptance tests. For most of the modules a trivial test should be easy to add

Right now we have an ERB template that looks at a file pattern[4]. This needs some other solution. I'm not expecting large difficulties but it's important to not waste CI minutes.
Another way could be to have a separate file for actions including Beaker and excluding. Perhaps someone could also write a version for Litmus that way.
* Handle beaker facts & excludes
Using ERB we have the option to expand the matrix with additional facts[5].  A common use case is to duplicate the entire matrix for My Software v1 and then another for v2. Other examples I have thought about were multiple beaker suites. Right now this sees little use so it's less important. Perhaps it can be solved via inputs but I haven't tried yet. It would be good if we can generate a nice name for that.
The same goes for excludes.
* Release work
We also have a release workflow but I haven't started with that.
I'm sending this email for visibility. I'll also note that right now I have little time to work on this. However, I'd like to start the discussion. Perhaps this is even something Puppet itself might want to host, if we can unify workflows.
[1]: https://docs.github.com/en/actions/learn-github-actions/reusing-workflows
[2]: https://github.com/ekohl/gha-puppet
[3]: https://github.com/voxpupuli/puppet-example/pull/15
[4]: https://github.com/voxpupuli/modulesync_config/blob/a7c683a828332429852a6521598c7ce8652f016a/moduleroot/.github/workflows/ci.yml.erb#L59 [5]: https://github.com/voxpupuli/modulesync_config/blob/a7c683a828332429852a6521598c7ce8652f016a/moduleroot/.github/workflows/ci.yml.erb#L70-L89