-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Unable to check out SSH submodule using deploy key #183
Comments
Does the ssh-key have access to both repos? Or are you using a deploy key (access to only one repo)? |
The ssh-key that I'm supplying to the action/checkout action is only authorized for the submodule (sfdx-common). I presumed that the repo that the workflow is running in would already be implicitly authenticated. Do I have that part wrong? |
Oh I see. Currently if you supply an SSH key then it's used to checkout the main repo and submodules. |
Since one of the features of checkout@v2 is to persist the creds on disk to enable easier scripting authenticated git commands, I think using the provided sshkey for the main repo makes sense (remote url is configured with the ssh url and core.sshCommand is setup for auth). Looking into multiple keys... |
It looks like What do you think about being able to specify multiple ssh keys. For example: ssh-key: |
${{ secrets.my_main_repo_deploy_key }}
${{ secrets.my_other_repo_deploy_key }} I think if one doesnt work, it will fallback and try the next. To be clear, this currently won't work - would need to update the action to support it. Would that be a good solution? |
I have to back up a second and ask how the checkout action works today ... Is it the case that whatever implicit authentication scheme that is used provides only read-only access to the repo it's running against? i.e. if I were to switch over to using deploy keys for this, would I lose the ability to commit back to the repo? (this isn't a use case I have today, but have been asked by a few team members if we could commit build artifacts back to the repo or to tag a release .. long story) Second, by switching over to require SSH, it increases the burden of configuration. I need to set up deploy keys for both repos. Not a huge burden, but it does make things more complex. And then there's that rule about not being able to use the same private key for more than one repo's deploy-key, right? "Key is already in use" if you try to use the same private/pub key pair as a deploy key? That's a huge drag that we've had to work around by creating a dedicated paid Github user (we're on a paid Teams plan) to act as a service user just so we can bless that user with readonly access to a bunch of repositories. So, yes, what you propose would work, but I think it's going to frustrate a lot of people. You may need to support multiple SSH keys anyway if a repo has multiple submodules .. so I can see why you're thinking along those lines. |
The default token - i.e.
No. When creating a deploy key, there is a checkbox to Allow write access.
Have you considered granting the service account read access to the main repo also? If in the future you want to commit back, the default auth token is still embedded in the config too ( |
It sounds like the only real option is to use the service account to grant access to both repos .. and yes, we can do this. But again, it sounds more convoluted than dealing with the submodule checkout myself (with the ssh-agent action) I would definitely prefer for the repo that the workflow is running in to be implicitly authorized and only have to deal with SSH authorization for submodules. But so far it sounds like I'm the only one that's given this a whirl :-) |
Proposed here: #190 |
Great! Though I looked at the PR and it looks just like copy changes? I don't see code changes |
It was a proposed change to the spec, but prevented other scenarios. As part of the discussion we figured out separate inputs |
Nope, you are not ;-) I already use a deploy key to pull in a python dependency from another private repository 'B' into the build of our repository 'A'. For this to work, i set up a private key via a configured secret in 'A' and the respective public key in 'B' and use the following step:
I am tempted to simply clone the submodule in another custom step until the checkout action officially supports it again :) |
I like that idea (if it works technically). On GitHub the problem is, that we need one key for each submodule. AFAIK the idea in PR #190 will only allow one key for all submodules. But we need multiple if we have multiple private submodules. Therefore +1 for this idea. Thanks! |
I am having the same problem - I have a private repository within organization, which uses multiple public submodules and one private submodule, therefore one key isn't enough. It would be nice to support multiple SSH keys - at least for now. |
I'm having a similar issue #271 |
I'm experiencing this issue as well |
Just another idea for the same core use case.
Seems a couple of community actions do something similar already, would prefer a core one for something this basic though. |
or
and the second uses detects a git repo in the current directory already and doesn't attempt to get that one again, and detects submodules is an array, and only does a subset of modules instead of all of them. |
I was able to checkout the submodules without this action, but manually. Here is what I did:
The key thing is that
Pretty smooth process (!) :) but hey, it worked! Hope this helps someone else. I'm sure there must be an easier solution. edit: here is a blog post that does something similar: #116 (comment) |
You'll need to checkout each of them individually. Not that hard as you may expect:
|
Just want to pass along my working version which will use the correct refs: - name: Main Checkout
uses: actions/checkout@v3
- name: Clone Submodule
run: |
mkdir -p $HOME/.ssh
echo '${{ secrets.SSH_SUBMODULE_PRIVATE_KEY }}' > $HOME/.ssh/ssh.key
chmod 600 $HOME/.ssh/ssh.key
export GIT_SSH_COMMAND="ssh -i $HOME/.ssh/ssh.key"
git submodule set-url ${{ env.SUBMODULE_PATH }} git@github.com:${{ env.REPO }}.git
git submodule update --init --recursive
git submodule set-url ${{ env.SUBMODULE_PATH }} https://github.com/${{ env.REPO }}.git
unset GIT_SSH_COMMAND
env:
SUBMODULE_PATH: src/shared
REPO: myapp/shared Based on this Stack Overflow: https://stackoverflow.com/questions/71400819/pulling-from-a-private-submodule-github-repository-using-a-deploy-key |
Nice, thank you very much. |
Moving this thread from #116 over here
@ericsciple -- just tried the new ssh-key param but no joy .. (the SSH private key that I'm passing in via Secret is one that works with the ssh-agent hack I described earlier in this thread)
And my workflow YAML looks like
And my .gitmodules is
The text was updated successfully, but these errors were encountered: