Github-action: action in private repository

Super helpful broken down tips!

1 Like

@jef I am trying your example implementation and am getting a strange error: ##[error]Top level 'runs:' section is required for /home/runner/work/#####/./.github/actions/service-deploy/action.yml. I simply copied my working action from the repo it was running in into a github-actions private org repo and am referencing it like you are in your example. Any ideas why that error would be popping up?

I am also getting the Unrecognized named-value: 'secrets' when trying to use secrets in the action template. Is there a way to utilize secrets without having to pass them as environment variables in each repo that uses the action template?

I’m thinking that you’re referencing the action wrong. What you want is something like this:

# --snip--
      - uses: actions/checkout@v2
      - uses: actions/checkout@v2
          repository: organization/private-actions-repository
          token: ${{ secrets.PRIVATE_SCOPED_PAT }}
          path: .github/actions
      - name: Service deploy
        uses: ./.github/actions/sevice-deploy

The directory structure of your private action repository would look like this:

.                     # the root of the repository directory
├── .git
├──         # not necessary, but for demonstration purpose
├── service-deploy    # reference this directory, not the action.yml
│   ├── action.yml
│   ├── Dockerfile    # just an example, doesn't need to be a Docker action
│   ├──

It seems you were trying to point to the action.yml file here. You’d want to reference the directory, not the action.yml.

To reiterate, private and action aren’t required naming here either, just the way it could be potentially structured.

This is not possible to my knowledge. You could use a different secret manager and action that would pull from those secrets based off a master secret. Or I would use organization secrets (what I think is better here).

1 Like

This is the structure of my private action repository:
. # the root of the repository directory
├── .git
├── service-deploy # reference this directory, not the action.yml
│ ├── action.yml

And my repo trying to use it has the workflow defined like this:

name: Build and Deploy to GKE

      - master


    name: Setup, Build, Publish, and Deploy
    runs-on: ubuntu-latest
      - uses: actions/checkout@v2
      - uses: actions/checkout@v2
          repository: <org>/github-actions
          token: ${{ secrets.REPO_TOKEN }}
          path: .github/actions
      - name: Private Action
        uses: ./.github/actions/service-deploy
1 Like

I’m also using organization secrets which is why I’m confused as to why it doesn’t work as it does in the other repo.

The weird thing is that runs is not a top-level section that I can see from the docs.

Not quite sure what you mean from this one.

Ensure that it’s added to the repository that is running the action from the organization.

That looks good to me. What sort of output are you getting? I’d be sure to also make sure that you don’t currently have a directory in .github/actions in the repository as it will overwrite it when you do the second checkout if you relied on anything in there.

What if we had an authorised key in workflows; for private repositories? This would be a top-level key, and accept an array of user logins.

If a request to use an action in a private repository comes from an authorised user/account it’s granted access, else it’s denied.

name: My Private Repo Workflow

    # .../

    - user_login_1
    - user_login_2
    - etc

    # .../

Private action repos would be very helpful.

A better approach would be to make it seamless like public actions from the Marketplace for private actions for enterprise customers.
One way to achieve this would be to let organisations have private Marketplace where they can publish their actions. Have all repos authorised against the private market place on org level and then use you private actions in an identical way to public actions.

I believe GH should definitely consider this approach given that they are already supporting private learning labs for organisations! The same pricipals apply to Actions and even more so given that Actions are going to be the most used thing an org will consume on day to day basis!




This is explained at

Note that in the SO answer, steps is incorrectly given twice.

It looks like this feature has been pushed to Q2 20201 now :frowning:

Workarounds look ok in the meantime.

Pushed to “Future”, not even Q2… :disappointed:

1 Like

It seems dependabot already supports private github-actions updates. Basing my conclusion on this documentation.

Question now is, how do I refer to my private github action in my workflow?

I started using this workaround, and it did work well for some time. However, I am seeing failed builds now with errors like the following:

 /usr/bin/git submodule foreach --recursive git config --local --name-only --get-regexp 'core\.sshCommand' && git config --local --unset-all 'core.sshCommand' || :
  Error: fatal: No url found for submodule path '.github/my-private-github-actions' in .gitmodules
  Error: The process '/usr/bin/git' failed with exit code 128

where .github/my-private-github-actions is the directory where actions/checkout@v2 is checking out the shared GHA (private) repository. Note that we do not use submodules, so the message doesn’t exactly make sense.

We are also using self-hosted runners, which may or may not be a factor with this.
See also:

I suspect this is related to the two checkout action post-step cleanup phases (one for the project own checkout and one for the shared actions repository checkout) that somehow trip up on one another.

Moved back to Q1! There is hope \o/

Actions: Centrally managed workflow templates · Issue #98 · github/roadmap

Moved to Q3 now :frowning:

Seems like it was moved to future again

Looks like 21Q1 → 21Q2 → 21Q3 :sob:

Having to include GH keys in your repo to do checkouts from other repos is a quite insecure hack (e.g. if one build is compromised, it can spread to other repos). Really wish GH would add private templating (e.g. using private actions cross repo) as it’s a standard feature in most CI/CD vendors.

Seems like the bigger problem is that GH never solved cross repo permissions. We can already grant Organization Secret access on a per repo level, why not grant checkouts on a per-repo level? That would solve both this Actions gap, and the lack of formal support for git submodule checkouts in Actions.