How to reuse a whole workflow?

[obfischer]

Hello everybody,

I think I had a fundamental misunderstandig of Actions. So let me ask something first:

A job in a workflow consists of one more more steps. Steps can use other Actions. But an Action is something else than a workflow, as an Action executes only a single command.

Is this correct?

If my current understanding is correct, how can I share an entire workflow with multiple steps with multiple repositories?

Best,

Oliver

[eb250130]

It seems that in addition to the workflow templates there is also going to be (it’s in the roadmap) an ability to define a workflow on organization or enterprise level github/roadmap#52

[acobaugh]

Workflow templates involve a one-time copy from another repo. What I think a lot of people are asking for is essentially the ability to include workflows from some shared repo, so there is only one place to update workflows. Gitlab supports this using syntax like this:

include:
  - project: k8s/gitlab-ci-templates
    ref: master
    file: helm-charts/.gitlab-ci.yml

When you have hundreds of repos, this is absolutely a show-stopper.

[Kurt-von-Laven]

Workflow templates may be of interest to some of you. I haven’t tested them out yet, so I am not sure whether that addresses your needs or not.

[SrBrahma]

+1, this is truly important. I want my npm packages to have the same publish workflow. Setting it for all of them isn’t impossible but it isn’t that maintainable to change them all when needed.

[kammce]

+1 this issue. I have a set of repos that I’d like to all share the same universal workflow.

[binhex]

yep add me to the list, i also want this!, seems a fairly obvious thing to want, i currently have 60 repo’s copying the same workflow file 60 times is not fun, i will of course automate the copying in some manner but this should be easy enough for github to include a mechanism to do this, its just a waste of time of time and disk space.

[vesubramanian]

I am also looking for a similar feature. Also, do we have anything similar to Jenkins Shared Library?

[jtbayly]

Just wanting to follow up on this and ask if anything has changed…?

[sfynx]

@agarthetiger I am under the impression that this all means that it is available under the enterprise subscription on github.com, not just the on-premise one. We currently have a Team subscription at work with 20 developers, so that would be a big price increase if we would want to re-use workflows efficiently in the future…

[agarthetiger]

That issue also has the “cloud” label which I thought meant that the feature would also be available on github.com as well as in GitHub Enterprise?

[sfynx]

It looks like it is intended to be an enterprise feature: github/roadmap#98
Which is a shame, because small teams that also have multiple projects with the same workflow would still have to resort to all kinds of workarounds.

[jbrunton]

The lack of built in support for this problem led me to create a CLI tool that wraps existing templating engines (ytt or Jsonnet) to manage workflows more effectively. In case it’s of interest: https://github.com/jbrunton/gflows

[ygottschalk]

Isn’t it possible to have these workflows in a submodule, include that at say /submodules/workflows/ and the have symlinks / hardlinks at /.github/workflow.yml -> pointing at /submodules/workflows/workflow.yml
this way it should be possible to “select” which workflows to really use in the sepcific repo and even use different branches on different repos.

[diversit]

Struggling with the same issue. We have over 50 repo’s and I have some very simple workflows to just label, approve and merge PR’s which need to be applied to all. These unfortunately cannot be put into a single workflow since they act on different events.

I have been trying using a submodule but this does not seem to work. The .github folder now is a submodule, but the workflows in it are not executed anymore.

[sfynx]

I’m wondering if anything is on the roadmap for this, it is a long requested feature. We would love to get rid of Jenkins as it has its flaws, but as we rely on Jenkins shared libraries we cannot migrate to GitHub Actions until a similar feature is introduced. We simply need a way to define a pipeline/workflow for building a certain project type, which can be used by many repositories, and without having to change all these repositories when we need to fix something in the workflow.

[timramone]

Why is this thread marked as solved? It’s not solved by any means, reusing a workflow doesn’t seem to be possible in any way – I have copy & pasted my configuration to about 15 projects and each time I want to make a change, I currently have to do it in 15 repositories …

Totally agree, sharing worklows between repos would be a great feature

[Jeehut]

Why is this thread marked as solved? It’s not solved by any means, reusing a workflow doesn’t seem to be possible in any way – I have copy & pasted my configuration to about 15 projects and each time I want to make a change, I currently have to do it in 15 repositories … ☹️

[obfischer]

From the docs: “You can write individual tasks, called actions, and combine them to create a custom workflow”

Yes, I missed this sentence. 😕 But this is that I was afraid of. It would be nice to be able to share workflows.

I will see that fits best my use case. Copying or using a Git submodule.

[logankilpatrick]

Hey! If you are a little fuzzy on what a GitHub action is and how it’s used, check out this link: https://help.github.com/en/actions/getting-started-with-github-actions/about-github-actions#about-github-actions

From the docs: “You can write individual tasks, called actions, and combine them to create a custom workflow”

If I am understanding your question right, you want to share a workflow between repos? I am not sure you have have a shared set of workflows between repos. The workflows and actions operate on a repo by repo basis. 

If you want to copy a workflow from one repo too another, you will need to copy the “.github” folder from one repo to the next. This will move over all of your workflows and subsequent actions.