Reusable Workflows from private organization repository

[gazandic]

Hello Team,

I am working on reusable workflows. I have a reusable-workflow repository for collection shared workflows. The repository make changes adoption can be implemented as soon as possible when the shared workflows changes.

However, the repository must be a public repository in order to do that.
https://docs.github.com/en/actions/using-workflows/reusing-workflows.
Starter workflow is not our cup of tea because we can't force changes adoption and make adoption time slower.

I want to reuse workflow from private repository because of security considerations, Are we able to do that?
Are there any roadmaps or timelines for this feature ?

Regards,

[HariSekhon]

I contacted GitHub Enterprise support about this a few months ago and was told it's on the roadmap.

I believe it should be possible now to use internal repos as reusable workflow repo sources but I haven't tried it yet as I prefer to work with my open-source library, which you might find interesting:

https://github.com/HariSekhon/GitHub-Actions

[robwafle]

@github-staff: This feature would be very useful. Any update would be greatly appreciated. I spent the last 30 minutes trying to find some indication if this is on the feature roadmap or under development but I found nothing.

[alexandervandekleutab]

I am also looking for this feature. I am curious if there is something difficult about implementing it. We use GitHub enterprise and GitHub Actions for our CI/CD.
We have many microservices stored in separate repos, and want to share the common workflows related to testing and deployment in one repo and use them in our other repos. However we cannot make the workflow public for security reasons.

For now we are using a workaround where download a workflow on-the-fly following the solution here: https://stackoverflow.com/questions/71118955/how-to-have-the-github-workflows-sharable-or-reusable

A possible solution for private repos is to upload the shareable repo as an artifact, e.g. a compressed archive and host it somewhere accessible. When the caller workflow kicks in, simply download the archive and extract it into the current context.

E.g.:

Assuming $archive-url =https://example.org/shareable-workflow.tar: workflow.yml

jobs:
  - name: Checkout context repo
     run: actions/checkout@v2

  - name: Download the shareable workflow
     run: curl $archive-url | tar xzf -  

  - uses: ./workflow.yml

[HariSekhon]

@kalanatd If you're not on Enterprise then I'd recommend creating very generic reusable workflows in a public central repo and passing in parameters to anything specific to your company which will live in your private repos.

This will also encourage you to write better more generically reusable code as there will be nothing company or environment specific in your public repo and the workflows will be fully parameterized and reusable.

Here is my public reusable workflows repo for an example:

https://github.com/HariSekhon/GitHub-Actions

[kalanatd]

@HariSekhon Makes sense and thank you very much for all the help. I will follow the parameterizing of the workflow path.

[gazandic]

I am also looking for this feature. I am curious if there is something difficult about implementing it. We use GitHub enterprise and GitHub Actions for our CI/CD. We have many microservices stored in separate repos, and want to share the common workflows related to testing and deployment in one repo and use them in our other repos. However we cannot make the workflow public for security reasons.

For now we are using a workaround where download a workflow on-the-fly following the solution here: https://stackoverflow.com/questions/71118955/how-to-have-the-github-workflows-sharable-or-reusable

A possible solution for private repos is to upload the shareable repo as an artifact, e.g. a compressed archive and host it somewhere accessible. When the caller workflow kicks in, simply download the archive and extract it into the current context.
E.g.:
Assuming $archive-url =https://example.org/shareable-workflow.tar: workflow.yml

jobs:
  - name: Checkout context repo
     run: actions/checkout@v2

  - name: Download the shareable workflow
     run: curl $archive-url | tar xzf -  

  - uses: ./workflow.yml

Thanks for the idea.

I used starter workflow to make initial template, i can't use internal repo because my project is not an Enterprise Subscription.
The initial template is fetching script from another source (you can use 3rd party like GCS, AWS, or even github repo for cloning) (make my script secured).
This will make sure the script is auto updated, but this will rely on network a lot

I'm still hoping that we can use reusable workflows in private repository.

[Breich90]

not only do you have to be paying for Enterprise but you have to have an Enterprise account created (even when you're a single organzation) in order to even enable the internal repository type. Very confusing/annoying

[chicco785]

did anyone actually make the above example work?
i think it's not possible:

1. the syntax for job is actually different, this looks more the syntax for steps
2. afaik, you cannot share the code base between two jobs.

any hint?

[fabiocaccamo]

@gazandic I know that this answer doesn't fit your needs perfectly, but it could be a good solution.

• Make your workflows use options wherever they use sensitive data

• Make your workflows public GitHub actions.

• You can now use your public workflows in all your repositories, use them always at the latest version to be sure that when you publish a workflow update your repositories will automatically use the latest version of the workflow.

• Pass options to workflows using GitHub Action Secrets.

I hope it can be helpful.

[gazandic]

@gazandic I know that this answer doesn't fit your needs perfectly, but it could be a good solution.

• Make your workflows use options wherever they use sensitive data
• Make your workflows public GitHub actions.
• You can now use your public workflows in all your repositories, use them always at the latest version to be sure that when you publish a workflow update your repositories will automatically use the latest version of the workflow.
• Pass options to workflows using GitHub Action Secrets.

I hope it can be helpful.

Thanks for the solution, but I won't make my workflows public repositories.
I used starter workflow to make initial template, i can't use internal repo because my project is not an Enterprise Subscription.
The initial template is fetching script from another source (you can use 3rd party like GCS, AWS, or even github repo for cloning).
This will make sure the script is auto updated, but this will rely on network a lot.

I'm still hoping that we can use reusable workflows in private repository.

[hania-elayoubi]

• It looks like this is the roadmap issue for this: Actions: Reusable workflows work with private repositories github/roadmap#51 , and its status is Q3 2022

[madhifallah]

• It looks like this is the roadmap issue for this: Actions: Reusable workflows work with private repositories github/roadmap#51 , and its status is Q3 2022

Status has changed : Status: Q4 2022 – Oct-Dec 😭

[chaddyc]

Gee, I am also looking for this specific feature, I have browsed Q&A forums left, right, and center. Then I came across this discussion. Really hope that feature is implemented soon.

[chrisRedwine]

It has the github enterprise label, so I wonder if they're just planning to broaden the existing internal repo sharing capability (for enterprise accounts) to include private repos (for enterprise accounts)?

[karlparry]

This is now possible on GitHub.com:
https://docs.github.com/en/actions/creating-actions/sharing-actions-and-workflows-from-your-private-repository

It is still not possible to do this on GitHub enterprise server though

[Breich90]

this is enabled/available on github cloud enterprise--did you mean it doesn't work on enterprise server?

[chicco785]

it would be good if private workflow could be reusable also in public repositories within the same organization. in this way, we won't have to expose the logic of the workflow, but we could still use the workflow.