When checking out a repo on Github Actions workflow, how do I pass in a key for a private submodule but not the repo itself?

[sfullerbeckman]

When checking out a repo on Github Actions workflow, how do I pass in a key for a private submodule but not the repo itself? This is currently how I am doing it: The ACCESS_KEY is the private key of a deploy key which is stored in the main repo. That key should only apply to the submodule and not the repo itself though. How can I force that functionality? Currenly I get an error because it is trying to use the SSH key to checkout the main repo.

- uses: actions/checkout@v3
  with:
      submodules: 'true'
      ssh-key:  ${{ secrets.ACCESS_KEY }}

[rosasurfer]

Same here. The main repo should always use the provided $GITHUB_TOKEN. I guess a workaround is to setup a machine user (service account) and use one user key for both main and submodule repo. In our case our organization has limited seats, so we don't want that. GHA is mostly used by organizations, so PATs don't apply here either.

There are countless issues here about private submodules not working and I'm surprised it's not clearly documented. Why is there no SSH config option per submodule? Obviously we are missing something here.

[DaAwesomeP]

Associated issue: #924

[cardoe]

And #973

[DaAwesomeP]

This following configuration is working for me, although it is unfortunate this required an additional action:

- uses: webfactory/ssh-agent@v0.5.4
  with:
    ssh-private-key: |
      ${{ secrets.PULL_KEY_REPO }}
      ${{ secrets.PULL_KEY_SUBMODULE_OTHERREPO }}
- uses: actions/checkout@v3
  with:
    submodules: 'recursive'
    persist-credentials: false

• secret PULL_KEY_REPO: Deploy key (private key) for this repo running the action with SSH key comment of the name of this repo (git@github.com:owner/repo.git)
• secret PULL_KEY_SUBMODULE_OTHERREPO: Deploy key (private key) for a private submodule repo running the action with SSH key comment of the name of the submodule repo (git@github.com:owner/otherrepo.git)
• Deploy key (public key) in this repo running the action
• Deploy key (public key) in this the submodule other repo

Everything is tightly scoped so that this repo/action can only access repos for which it has a deploy key. I would not recommend sharing deploy keys between multiple actions/repos. This method also pulls public HTTPS submodules just fine.

[andrew-constantinescu]

Nevermind! I had added the submodule private key as a secret to the submodule repo, when it should be the main repo as you clearly stated! Works for me too! Thanks for the detailed breakdown @DaAwesomeP !!

[sfullerbeckman]

Works perfectly on Ubuntu. Fails on Windows 😢

The interesting thing is that I still get the Comment for (public) key '' does not match GitHub URL pattern. Not treating it as a GitHub deploy key. error on both ubuntu and windows, and ubuntu worked. So that must not be the issue. It must be the checkout action that is somehow failing on Windows

[sfullerbeckman]

I noticed that the fetch commands are actually different between the two platforms.

Windows 👇

"C:\Program Files\Git\bin\git.exe" -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +4bd1373d4f350ad95520dec7a9e33c27326ccd55:refs/remotes/origin/[branch name]

Ubuntu 👇

/usr/bin/git submodule sync --recursive
/usr/bin/git -c protocol.version=2 submodule update --init --force --depth=1 --recursive

[sfullerbeckman]

I got it to work on Windows by doing the submodule checkout manually. I also had to register the ssh keys after the initial checkout because for some reason it couldn't pull the action repo. This is what I did...

jobs:
  build:
    # The type of runner that the job will run on
    runs-on: windows-2019
    timeout-minutes: 15

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      
      - uses: actions/checkout@v3
        with:
          persist-credentials: false

      - uses: webfactory/ssh-agent@v0.5.4
        with:
          ssh-private-key: |
            ${{ secrets.PULL_KEY_REPO }}
            ${{ secrets.PULL_KEY_SUBMODULE }}

      - run: |
          git submodule sync --recursive
          git -c protocol.version=2 submodule update --init --force --depth=1 --recursive