Hi,
The document states: “To use an action defined in a private repository, both the workflow file and the action must be in the same repository. Your workflow cannot use actions defined in other private repositories, even if the other private repository is in the same organization.”.
Will this be a definitive limitation? Or it will be removed for example with the new “Internal repository visibility (beta)”?
Would be great to share action within the org.
Thanks in adavance
Andrea
Hi @apiloqbc,
Thanks for being here and apologies for the delay in response, as of this moment we don’t have any information to share, please know however that I’ve passed on your request to the team and your feedback is correct hands.
I would love to have inter-org access to private repos that are used as actions. I just got bit by this while building out an action in a private repo and finally getting it hooked up to use in another private repo within the same Org. It’s not that we can’t make the action repo public, it’s that we don’t want to if we don’t have to.
Can you elaborate on how you went about referencing intra-org private Actions in other repos within the Organization? I’m working on this now and receiving 404’s in the consuming repository.
Example:
- TestOrg
- Repo: Action-Test (private)
- Repo: Repo-Using-Action (private)
That is exactly the issue we were running into as well. It gave 404’s attempting to download the Action, even though the repo was in the same organization but private.
I’ll be trying to use a repo local action as a temporary workaround. Everything in the docs right now touts “public”. Maybe we’ll see some sort of token passing for the uses field to enable private actions utlization.
Docs: Example using action in the same repository as the workflow
This!!! There is a pretty big need to be able to use actions from private repositories that are on the same organization.
+1 for this. Currently evaluating using github actions for my workplace amongst 160 private repositories. There may be a way around it for us but it seems odd that we don’t have this option within the same organization. We have some 100+ repositories, I don’t really want to make a repo public just so it can be shared here, nor do I particularly want to duplicate code 100+ times.
This could be a deal breaker yet for using github actions but hopefully there is a way I can achieve what I want which is basically common methods for deploying a repositories code into the cloud. Maybe there’s shared code around that I can use somewhere yet.
I found this but no such luck as of yet.
We just created a common actions repo, cloned it and used it in the job. It’s not very clean, but works for the time being.
That was my thinking for how to get around this as well but it seems like I shouldn’t need to. If it carries on that’s what I’ll be doing though. Thanks for letting us know you got it working.
If you are interested, I’ve created an action to support this scenario: https://github.com/marketplace/actions/bagbyte-use-private-action
oh, this is a huge deal breaker. We were just looking into using this for our private repos and we need to develop some custom private actions as well. We can’t make the public.
I might hate myself for considering this, but how does github actions handle this being a sub module?
Ideally GitHub actions would natively support this feature without using sub modules but it could be a stop gap if nothing preventing it. Thoughts?
Too sad that this limitation wasn’t extended to organization level. Feels like the actions product is aimed for OOSS despite the price level for private usage.
This one piles on top of not being able to share secrets at organization level, not being able to manage secrets with the API, and more limits that make us hard to migrate from other providers (in my case circleci).
Hope this gets better in the next months
Perhaps using the external actions as git submodules would solve your problem?
Thought the same but the GitHub token generated for the workflow is scoped specifically for the repo, so you have to manually setup additional secrets for cloning or checking out submodules.
I help maintaining this and it solves another kind of problem.
Just in case someone else wondered: this is doable but requires an additional token capable of cloning the other repo to be added as a secret as the token made available to the action is limited to the repo in question. With no API for managing secrets, this introduces toil.
The workarounds mentioned here are great, but this needs to be added natively - as organisations cannot be expected to publicly share their actions.
Is there a roadmap for this?
I’ve noted InVision havea workaround for this too:
https://github.com/InVisionApp/private-action-loader