It would be great if this action would also set the email and name. In order to do other git operations it is required. I am adding this to my actions to get around it:
steps:
- uses: actions/checkout@v1
- name: Setup git user
run: |
git config --global user.name "$(git --no-pager log --format=format:'%an' -n 1)"
git config --global user.email "$(git --no-pager log --format=format:'%ae' -n 1)"
Unfortunately I don't have access to the user email. It seems like these can come from the account in a more clean way here, but I guess I could also create my own action. Since this is so new I am not sure what the best way forward is so thought I would post here.
@chrispat for feedback.
This would be useful for users willing to update gh-pages hosted on separate repos using a deployment key (e.g. https://github.com/1138-4EB/vunit/blob/migrate-to-gha/.github/workflows/push.yml#L63-L74). This is specially so, because GITHUB_TOKEN's scope is limited and personal access tokens are not scoped to a single target repo.
This would be useful for users willing to update gh-pages
This was actually my first use case for this!
https://github.com/pkgjs/gh-pages/blob/master/entrypoint.sh#L4-L5
I recently wrote an action that sets up the user and email the @action user, so you can also push back to the repo, as long as you use the v2 of actions/checkout
https://github.com/fregante/setup-git-user
steps:
- uses: actions/checkout@v2
- uses: fregante/setup-git-user@v1
Old action
I recently wrote an action that sets up the user, email and token in one go, so you can also push back to the repo.
https://github.com/fregante/setup-git-token
- uses: fregante/setup-git-token@v1
with:
token: ${{ secrets.GITHUB_TOKEN }}
name: The Bot
email: [email protected]
@ericsciple, should this issue be closed now that #107 is merged? It seems to be included in v2: https://github.com/actions/checkout/commits/v2
So that PR is a bit hard to grok on my phone (even with the improvements in the GitHub app), but it is unclear if that sets the name and email. This issue is specifically about that need. Does that PR solve this use case indirectly?
@wesleytodd, see:
https://github.com/actions/checkout/blob/3537747199ad29df25693bc607e99df5d7726ffd/action.yml#L12-L17
It seems to me that this issue was/is about "do other (authenticated) git operations"; precisely update gh-pages (which was/is your "first use case for this"). Explicitly setting the user and email would have been an approach. Using the token to do so is just another suitable solution.
Moreover, I think it would be desirable to support optionally using deployment keys instead of tokens (be it the default or a PAT). This is because default tokens do not allow to update other repos; while PATs provide too many permissions. Nonetheless, even if keys were supported, I believe that setting the user and email would still be a side effect.
Therefore, I think that this issue should be either closed or repurposed to account for the new feature in master.
Awesome, thanks for the more clear explanation! I have never used the method I see in that PR, so one last question I have:
Does using a token for git auth also stop git from complaining about no user or email when committing?
Does using a token for git auth also stop git from complaining about no user or email when committing?
Although I'm not sure about that, I believe it should. The usefulness of the feature would be very limited otherwise.
Anyway, even if it works, there is currently a bug that prevents gh-pages from being updated when the token is used: actions/toolkit#247. Hence, you might want to keep using a deployment key.
Awesome, thanks for the more clear explanation! I have never used the method I see in that PR, so one last question I have:
Does using a token for git auth also stop git from complaining about no user or email when committing?
No, that does not stop git from complaining. You still have to git config name and email. All what it does is that commits and pushes are well authenticated, but you should provide name and email before that. And yes, that limits the usefulness as @eine said.
+1 i didnt realize the built-in GITHUB_TOKEN has push permission... i'll open an adr shortly...
Also note, in the interim it looks like GIT_AUTHOR_NAME etc can be specified
I think this would be a nice feature. It would also lead to a more consistent appearance of commits created by GitHub Actions. I'm currently wondering which email address and username I should use for the time being.
github-actions <[email protected]>. However, this email is not recognized by the platform. GitHub displays the author of the commit with the generic icon and without a link.
github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>. This seems to work nicely. The author of the commit has the same icon and name as GitHub Actions everywhere else. The link goes to https://github.com/features/actions as I would expect. I'm just wondering if there is any caveat since it is not promoted in the README.md.
GitHub Action <[email protected]>. I don't know where this is comming from. GitHub seems to link it to some user but clicking on the user opens a 404-page. The icon and name doesn't match what is usually shown for GitHub Actions.
If there is no caveat for the second option, I would suggest that the checkout action configures Git accordingly if none of both options is already set. (Alternatively, GitHub's runners could be updated to use this configuration.)
@JojOatXGME - I don't know exactly where the user from your #3 is really coming from either, but I do see the below two GitHub Actions having examples using this 'user':
Searching GH for this shows there are currently over 7k+ workflows using this action, so it's also possible that there is a lot of 'copy&paste' workflow creation going on (I've done this myself, several times..) -> https://github.com/search?q=git+config+local+user.email+action%40github.com&type=code
No matter, thank you very much for the breakdown - an internet search landed me on this issue and your comment was exactly what I was looking for! I think this issue conversation, along with the "GitHub Actions bot email address?" conversation in the community forum is enough information for folks to figure out how to get the information needed to have the commit author show nicely on the GitHub interface.
All that to say, I would also love to see this feature request implemented, as it would be nice for GitHub workflow authors.
A quick hack that might be fragile, but also Just Might Work for most cases:
git commit -am message --author=.
per the docs
git-commit assumes the --author argument to be of the form: A U Thor <[email protected]>.
Otherwise
is assumed to be a pattern and is used to search for an existing commit by that author (i.e. rev-list --all -i --author= ); the commit author is then copied from the first such commit found.
So, in short: commit --author=. should copy the authorship from the previous commit since . as a regex will match all commits.
Most helpful comment
I think this would be a nice feature. It would also lead to a more consistent appearance of commits created by GitHub Actions. I'm currently wondering which email address and username I should use for the time being.
github-actions <[email protected]>. However, this email is not recognized by the platform. GitHub displays the author of the commit with the generic icon and without a link.github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>. This seems to work nicely. The author of the commit has the same icon and name as GitHub Actions everywhere else. The link goes to https://github.com/features/actions as I would expect. I'm just wondering if there is any caveat since it is not promoted in the README.md.GitHub Action <[email protected]>. I don't know where this is comming from. GitHub seems to link it to some user but clicking on the user opens a 404-page. The icon and name doesn't match what is usually shown for GitHub Actions.If there is no caveat for the second option, I would suggest that the checkout action configures Git accordingly if none of both options is already set. (Alternatively, GitHub's runners could be updated to use this configuration.)