Example for sharing an entire workflow with other repositories

[hendrikmaus]

Would you have an example on how to share an entire (templated) workflow with other repositories?

I am using ytt as a templating engine and created a repository containing a templated workflow. Now I was looking into gflow packages to share it with other repositories.

However the first thing I fell over was the values file; I had to copy the keys I created inside of it to the repository I wanted to include the workflow in. This would mean that users would have to do that manually as gflows update would simply fail. I reckon there is a better way to do that.

Another issue I am facing is that the workflow is accompanied by a script file - is there a way to include a non-yml file in a gflow package?

[jbrunton]

Hi @hendrikmaus,

Would you have an example on how to share an entire (templated) workflow with other repositories?

You can certainly use GFlows packages to share workflows. I added a simple example here which is now used in the setup-gflows repo to define a workflow for tagging releases. Note that the git user details are defined in the values file (see config.yml and values.yml for how the package is used and configured).

However the first thing I fell over was the values file; I had to copy the keys I created inside of it to the repository I wanted to include the workflow in.

Regarding values files, there are a couple of different scenarios they may be used in:

1. The workflow in the GFlows package is shared across repositories, but each repository may provide different values (e.g. they might each have a different main branch). In such a case, each repo would have its own values file at .gflows/libs/values.yml. (This is the scenario in the example above.)
2. The workflow in the GFlows package is complex and you want to factor out constants into a values file specific to that workflow. (Or, maybe the package contains multiple workflows and you want to share certain values between them.) In this case, typically those values would not be overridden by the repositories using the workflows (although they still could be). This can be achieved using ytt overlays, but I must admit I haven't used this case myself. (You could also define functions in a lib file which return the constant values. There are some trade-offs between the two approaches.)

From your description, it sounds like you're interested in the second case, is that correct? I can provide some further details if so, but I'll wait for your confirmation before getting into the details of overlays.

Another issue I am facing is that the workflow is accompanied by a script file - is there a way to include a non-yml file in a gflow package?

Regarding script files: GFlows is designed to output a single workflow file (or at least, one file per workflow definition), so you can't use it to copy a separate script. If you have, say, a Bash script which you want to run as part of the workflow, the intended approach would be to define that script in the workflow template: you could extract it into a separate source file for maintainability, and merge it into the generated workflow file using the templating engine. Would that be feasible in your case?

If you really need a separate script, you would currently have to manage that by some other means (e.g. a Git submodule, or a step in the workflow to copy it from somewhere else). I can certainly see that it might be convenient to add a feature for this to GFlows, but it's not supported at the moment.