Reuse/import workflows

[fregante]

Describe the enhancement

Workflows tend to grow large once you start splitting some steps to run in separate jobs. Some other workflows are inherently large because they do a lot.

In many cases, I reuse the same workflow in multiple repositories and I wish I could just import it instead of copy-pasting it and manually updating it everywhere.

Code Snippet

I wish I could just use this in a workflow file:

import:
  - use: fregante/workflows@v1
    file: webextension-deployment.yml

and this would work as if I copied the whole file.

[sindresorhus]

The biggest reason I'm currently staying on Travis CI for existing projects is that the same config for GitHub Actions is more verbose and boilerplaty. Would be nice if workflows could be reused across repos.

[MarcosCela]

This will be a game changer to manage workflows on a big org.

[trevorbaca]

This would be great. Something like Travis's import command.

My workaround in GitHub actions is currently just a hard link in the to-be-tested repo.

[fregante]

I ended up writing my own tool to store my workflows in a repo and easily download/update them elsewhere:

https://github.com/fregante/ghat

[fidou]

Hi, I would like to use this functionality also from the same repo.
I am currently using github environments to deploy by executing 20 steps to deploy in an environment, and I have to do this 3 times (with slightly different parameters) on development, test and production.
It would be nice to reuse workflow working without the need of the central workflow library as my steps are very specific to my repository and my application.

[acobaugh]

IMO, the recently-released "Reusable Workflows" aren't really what this part of the community was looking for. As implemented, those appear to be just "workflows that can be called by other workflows with clearly defined input/output boundaries". The boilerplate still needs to be copied around to every repo, so they don't really do much to keep the per-repo yaml DRY.

However, similar to the OP's case, tools like Gitlab CI can do something like this:

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

and then nothing else needs to be placed in .gitlab-ci.yml. You can still override env locally. Gitlab also supports an extends keyword, so you can centrally define jobs, then reuse those jobs with extends while overriding different parts of those jobs for special cases.

Workflow Actions are sooo close. I think include/import function would knock github out of the park.

[iiro]

Completely agree with all of you on this. Not sure would this help everyone here, but have you seen this: github/roadmap#52 ? I was hoping to see this happening on Q2 next year but, now it's postponed to "Future" :/

We would be happy to use the "Reusable workflows" - but - we would need to consume them from a private repository, not a public one :/ (as this seems to be the current limitation atm: https://docs.github.com/en/actions/learn-github-actions/reusing-workflows)

[acobaugh]

I hadn't seen github/roadmap#52, but that looks like it's a universal "run this workflow on all repos", which isn't quite what I want. I want to define a workflow per language or project type, then reuse the entire workflow yaml file across multiple repos.

I think Reusable workflows are nice for some use cases, but because they don't inherit on or jobs or env, they're really just externally-defined workflows you trigger from locally-defined workflows. IMO, on, job, and env need to be reusable, too, to really be useful.

[github-actions]

Thank you for your interest in the runner application and taking the time to provide your valuable feedback. We kindly ask you to redirect this feedback to the GitHub Community Support Forum which our team actively monitors and would be a better place to start a discussion for new feature requests in GitHub Actions. For more information on this policy please read our contribution guidelines. 😃