Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for private submodules of private superprojects #924

Open
pbasista opened this issue Sep 15, 2022 · 7 comments
Open

Support for private submodules of private superprojects #924

pbasista opened this issue Sep 15, 2022 · 7 comments

Comments

@pbasista
Copy link

pbasista commented Sep 15, 2022

Hi, I have noticed that this GitHub action supports checking out git submodules. I have also noticed that it supports configuring a private SSH key for accessing the repositories that are supposed to be checked out.

However, it seems like in such a scenario it is currently impossible to use only one SSH key that has access to a private submodule but does not have access to the superproject (the repository it is embedded in).

Consider a scenario where a private GitHub repository org/A has a private GitHub repository org/B as a submodule.

User creates a Deploy key for org/B. And they attempt to use it in a workflow within org/A for checking out the org/B submodule via this action. I am unsure how to achieve that.

When the SSH key is not set up, then checkout of org/A succeeds. But checkout of org/B fails because the workflow runs on repository org/A and there is no private key for accessing org/B.

If the SSH key is set up to the Deploy key of org/B, then the checkout of org/B might succeed. But the checkout of org/A fails due to the mentioned SSH key. It seems like it is used to check out all GitHub repositories, including the repository on which the workflow runs. And the configured Deploy key for org/B does not have access to org/A.

Is there a way to configure this GitHub action to only use the provided SSH key to check out repositories that are different than the repository where the workflow runs? I would ideally like to avoid creating another Deploy key for org/A and then use it within a workflow on the same repository.

The SSH keys I use as the Deploy keys already use the comment format [email protected]:owner/repo.git that is recommended by the webfactory/ssh-agent action. But it seems to have no effect within the checkout action.

@sfullerbeckman
Copy link

I also have been trying to do the same thing and haven't figured it out. Either there is a way that I am just missing or this hasn't been implemented yet. I openned a discussion here. #928

@cardoe
Copy link

cardoe commented Feb 16, 2023

Relates to #973

@carlspring
Copy link

Any updates on this?

@segunjkf
Copy link

segunjkf commented Apr 5, 2023

I am also having the same error. Any update on this?

@plakhin
Copy link

plakhin commented May 14, 2023

I have org-x/repo-a with a submodule that is org-x/repo-b - another private repository of the same organization.

Getting not found error:

  Submodule 'resources' ([email protected]:org-x/repo-b.git) registered for path 'resources'
  Cloning into '/home/runner/work/repo-a/repo-a/resources'...
  remote: Repository not found.
  Error: fatal: repository 'https://github.com/org-x/repo-b.git/' not found
  Error: fatal: clone of '[email protected]:org-x/repo-b.git' into submodule path '/home/runner/work/repo-a/repo-a/resources' failed

Anybody knows how to solve?

@lesterli
Copy link

lesterli commented May 26, 2023

@carlspring @segunjkf @plakhin You can use submodules and ssh-key, and config a repository secret SSH_KEY for superproject repo (org/A or org-x/repo-a), the SSH_KEY's value is the SSH private key associated with your GitHub account.

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

It works fine.

@sfullerbeckman
Copy link

See my solution here: #928 (reply in thread)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants