-
Notifications
You must be signed in to change notification settings - Fork 10
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
Possible answer to private repository support #5
Comments
Cool thanks, yeh I am aware of the "Full control of private repositories" option, but i was specifically talking about supporting repos who use SSH urls for their submodules, despite githubs recommendation, there are good reasons (unrelated to automation) to use them. But really its a valid mode supported by
However like I said above i guess thats going to be a common use case for others so it should at least be available as an option to provide support for it I'll think about that one, Thanks for the feedback! |
Welcome for sure. What I was getting at is your Action likely is already able to handle private repositories via HTTPS URLs; setup is all Client and Workflow configured. I wont argue that SSH does allow for some extra fanciness, so provided that an name: 'git-submodule-action'
description: "Bump git submodules on '/submodules' comment"
inputs:
deploy_key:
description: 'Private key authenticated to GitHub'
required: false
runs:
using: 'docker'
image: 'Dockerfile'
branding:
icon: git-pull-request
color: blue ... the following Bash code should enable SSH authentication to GitHub... #!/usr/bin/env bash
if [ -n "${INPUT_DEPLOY_KEY}" ]; then
## Adds key from Action Input and sets permissions to read/write only for owner
mkdir -vp "${HOME}/.ssh/github_auth"
tee -a "${HOME}/.ssh/github_auth" 1>/dev/null <<<"$(printf '%s\n' "${INPUT_DEPLOY_KEY}")"
chmod 600 "${HOME}/.ssh/github_auth"
## Configures SSH authentication for GitHub
tee -a "${HOME}/.ssh/config" 1>/dev/null <<'EOF'
Host github.com
HostName github.com
User git
IdentitiesOnly yes
IdentityFile ~/.ssh/github_auth
EOF
## Add GitHub to known hosts if needed
if [ -z "$(ssh-keygen -f "${HOME}/.ssh/known_hosts" -H -F 'github.com')" ]; then
tee -a "${HOME}/.ssh/known_hosts" 1>/dev/null <<<"$(ssh-keyscan -H 'github.com')"
fi
fi
... then Workflows could look a bit like... uses: domdere/git-submodule-action@master
with:
deploy_key: ${{ secrets.DEPLOY_KEY }} ... which may or may not be a good idea depending upon permissions that are given to the deploy key used.
tee -a "${HOME}/.ssh/config" 1>/dev/null <<EOF
Host ${INPUT_HOSTNAME:-github.com}
HostName ${INPUT_HOSTNAME:-github.com}
User ${INPUT_USER:-git}
IdentitiesOnly yes
IdentityFile ~/.ssh/git_auth
EOF
Yeah recursion likely is not needed in this case, maybe Considering that directories containing a submodule are pointers/hashes to Git, there's likely some clever way of retrieving the latest commit reference for each submodule instead of downloading the whole history of changes. Adding |
We've got a number of repos all using another one as a submodule using SSH. I currently checkout the submodule in PR actions using this:
and then do some builds & run unit tests. I basically force PRs to have the submodule be within the last 10 commits to pass. I would love an easy way to bring them up to latest without manually checking out the branch and making a commit. |
Ah, nice, thanks for the suggestion, I'll look into it!
…On Sun, 26 Apr 2020, 10:23 am Frederic Morel, ***@***.***> wrote:
We've got a number of repos all using another one as a submodule using
SSH. I currently checkout the submodule in PR actions using this:
- uses: ***@***.***
# Checkout submodule
- uses: ***@***.***
with:
ssh-private-key: ${{ secrets.GA_CHECKOUT_SUBMODULE }}
- name: Checkout submodules (with 10-commit history for the next step)
shell: bash
run: |
git submodule sync --recursive
git submodule update --init --force --recursive --depth=10
# Verifies if submodule is pointing to a commit on master branch
# Being equal to origin/master or behind (by up to 10 commits) it is fine
# Being ahead or totally diverged is not
- name: Verify pointing to commit on master (will fail if pointing to unmerged commit or one older than 10 commits behind latest)
shell: bash
run: |
cd submodule_folder/
head=$(git rev-parse HEAD)
echo "Submodule commit: https://github.com/{org}/{repo}/commit/$head"
master=$(git rev-parse origin/master)
echo "Latest master: https://github.com/{org}/{repo}/commit/$master"
base=$(git merge-base $head $master)
echo "Latest in common: https://github.com/{org}/{repo}/commit/$base"
if [ $head == $master ]
then exit 0
elif [ $head == $base ]
then
echo "::warning file=.gitmodules,line=1,col=1::Submodule is not pointing to latest commit"
exit 0
else
echo "::error file=.gitmodules,line=1,col=1::Submodule is not pointing to master branch"
exit 1
fi
and then do some builds & run unit tests.
I basically force PRs to have the submodule be within the last 10 commits
to pass. I would love an easy way to bring them up to latest without
manually checking out the branch and making a commit.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAXRHUXK222FYU7TUAONDILRON5H3ANCNFSM4JEORG3Q>
.
|
@fjmorel Thank you for the example commands! I think it may be possible to avoid changing directories by utilizing the git submodule --quiet foreach git rev-parse HEAD
... once before update and then again after, at which point the hashes could be compared for changes. And by adding Combined those suggestions may look something like... - uses: actions/checkout@v2
# Checkout submodule
- uses: webfactory/[email protected]
with:
ssh-private-key: ${{ secrets.GA_CHECKOUT_SUBMODULE }}
- name: Checkout submodules (with 10-commit history for the next step)
shell: bash
run: |
old_submodule_hashes=$(git submodule --quiet foreach git rev-parse HEAD)
git submodule update --init --force --recursive --remote --depth=10
new_submodule_hashes=$(git submodule --quiet foreach git rev-parse HEAD)
if [ "${old_submodule_hashes}" == "${new_submodule_hashes} ]
then
printf 'No submodule changes/updates found\n'
exit 0
fi |
I ended up writing an action based on this that worked with my submodule:
There's probably a cleaner way to do this, but this works for me. |
If I remember correctly the
GITHUB_TOKEN
lacks permissions for private repositories.Not all is lost though, checking the permissions of
repo
("Full control of private repositories") when generating a new token athttps://github.com/settings/tokens/new
, and then overwriting the environment variable within Workflows that require more permissions should to the trick...... SSH setup should only be required if those utilizing submodules are also using SSH URLs; in my experience GitHub automation doesn't support SSH URLs and their documentation, if I remember correctly, recommends HTTPS instead; even for their own domain.
Small aside; I think if line
37
entrypoint
were...... it may eliminate the need for lines
38
through40
, though that may also download more than what's necessary to update the.gitmodules
file and directory-links.The text was updated successfully, but these errors were encountered: