@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

    - uses: fregante/setup-git-token@v1
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
        name: The Bot
        email: bot@example.com

@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:

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...