Reusable workflows in private organization repositories

As described here, GitHub Actions now makes it possible to reuse workflows under the following conditions:

  • Both workflows are in the same repository.
  • The called workflow is stored in a public repository.

This is quite limiting for organization (that have a GitHub subscription like “GitHub Teams”) that want to create reusable workflows that can be used across many distinct repositories (ex: 1 private repository defines a shared workflow and that workflow is reused by 50 other private repositories).

In my case, the shared workflows would have sensitive information (ex: AWS ECR registry url, AWS Code Artifacts information). Exposing all these details in a public repository would expose to the world the technologies that we use for building our products and how we do it. This gives more information to potential hackers.

With this in mind, my organization can’t use shared workflows which is a shame :cry: The feature would have made it possible to stop replicating yaml build scripts in about 40 repositories (one repository per micro-service).

So my question is: do you have plans to enable workflow reuse when the repository that contains the shared workflow is stored in a private organization repository?

38 Likes

I had the same realization, albeit probably slower than most. Hopefully, we can shine more light on this shortcoming.

1 Like

I faced the same limitation. Would really love to see it working with private organization repositories as well :rocket:

4 Likes

We have the same problem. We got very excited about reusable workflows (it’d let us kill off our fragile/time consuming custom automation to copy and patch workflow templates everywhere), then immediately very sad when we realized we couldn’t use them with our private GitHub Teams repositories.

1 Like

This is indeed an absolute must.
The operational maintenance burden we’re experiencing when changing workflows in every repo is a total nightmare … Please help us out :slight_smile:

2 Likes

Same. We have a workflow that could be used by at least 3 repos. Would love to share them internally, but not willing to make the shared workflow public

Same :frowning:

I’m having the same problem when trying to use a workflow in a private repository.

1 Like

This is such a missed opportunity. No organisation ever would like to have their CI pipelines as public repositories.

1 Like

Enterprises can use internal repositories. It’s what we are using.

2 Likes

There is a solution, however, it works only for enterprise users / organizations.

You can make the repository with reusable workflows internal instead of private and enable Accessible from repositories in the organization. It should do the trick and you will be able to reuse workflows placed there :slight_smile:

The whole idea of reusable workflows is great, but it feels a bit unfinished in many aspects, when you start using it. Hopefully, it will evolve quickly.

2 Likes

Really agree with all written above, we need this feature to be enabled in private repositories as well

1 Like

Are you using this solution? I ask, because you write “it should do the trick”.

I can confirm, that @titenkov `s solution is working even for enterprises.

This is simply missing in the documentation.

It is only available to self hosted github? Here at my company, it use Github Enterprise Cloud, and there’s no “internal” option…

image

image

2 Likes

+1 I’ve had a similar experience.
Using GHE Cloud, but there is no option for ‘Internal’ repositories

1 Like

+1, we’re using GHE and don’t have “internal” option. We really want to use this feature without setting our repo visibility to public.

Same here, being unable to reuse workflows stored in a private repo is quite frustrating. GitLab even allows to reference workflows via URL, which would be nice too.

but “private” repos are private. not “private except for the workflow which is public but public only to other workflows, not other people.”

“private” has meaning.

That’s why access token exists…

Wait, is this a GitHub Enterprise Cloud thing, where your stuff lives on gihub.com along with everyone else? things like this are why you want to host your own instance, but I can’t fault anyone for not knowing that ahead of time.