Short: Is it possible to run a GitHub Action which was generated partially by a parent GitHub Action for CI purposes?
Long: I have a use case where one repository is a generator of repositories. Specifically, it uses the Cookiecutter tech (https://github.com/cookiecutter/cookiecutter) on top which formats Jinja templating to create a new skeleton repository.
I want the parent (generator) to use a GitHub Action to test all the generator options, then I would like to have the skeleton (generated) GitHub Action trigger which contains the CI components for the skeletal output repository. This will ensure that not only did I set up the Jinja correctly so the skeleton generates, but also ensures the output skeleton is actually usable.
Ideally, I would like to know if it’s possible to feed one GitHub Action into another after it was generated. However, I understand that this would be a nightmare from environment/OS/spawning standpoint as you could theoretically chain them indefinitely and have a huge matrix of build envs/os by the end.
Given the above, there are a couple alternatives which would work well enough I want to float and see if the community has any thoughts or ideas on how to do this.
One option would be to execute only the specific jobs of the output workflow as part of the parent. Effectively reading the partial that is the jobs and then executing them in the same parent environment. This relies on manual work from my end, but that is a-ok since it gets the job done.
Another option would be to create a custom Action at the generator level which then executes a lower level workflow in a container. I’m not sure how viable this is or if someone has already done this before.
The last option would be emulating a GitHub Action run. I know of one tool which can do this (https://github.com/nektos/act), but I don’t think its quite what I need.
In theory, it would be possible to manually read the YAML file of the output workflow and parse it since I know what the output should be, but I want to avoid manually reading YAML if possible in case schema changes in the future (and I would have to parse all the workflow variables by hand). I’m also interested to hear if the community has other ideas for approaches too.