Return the GitHub App user id

[vleon1a]

Hello,

The action returns additional outputs thanks to #105, but it would be great to return also the GitHub App user id, which we can fetch using the GH CLI for instance with gh api "/users/<app-slug>[bot]" --jq .id. The rationale is that to get the commit authenticated properly, we have to use the user id and not the installation id (as also mentioned in this discussion. This was discussed in the mentioned PR, but somehow only the installation id was added to the outputs.

This is currently how I implemented it:

      - name: Generate GitHub App Token
        id: generate-token
        uses: actions/create-github-app-token@c8f55efbd427e7465d6da1106e7979bc8aaee856 # v1.10.1
        with:
          app-id: ${{ secrets.SEMANTIC_RELEASE_APP_ID }}
          private-key: ${{ secrets.SEMANTIC_RELEASE_PRIVATE_KEY }}
      - name: GitHub Release
        env:
          GITHUB_TOKEN: ${{ steps.generate-token.outputs.token }}
          GIT_AUTHOR_NAME: ${{ steps.generate-token.outputs.app-slug }}[bot]
          GIT_AUTHOR_EMAIL: ${{ steps.generate-token.outputs.installation-id }}+${{ steps.generate-token.outputs.app-slug }}[bot]@users.noreply.github.com
          GIT_COMMITTER_NAME: ${{ steps.generate-token.outputs.app-slug }}[bot]
          GIT_COMMITTER_EMAIL: ${{ steps.generate-token.outputs.installation-id }}+${{ steps.generate-token.outputs.app-slug }}[bot]@users.noreply.github.com
        run: npx semantic-release

Which leads to commits not properly associated with the GitHub App. So we would need to use the user-id instead of the installation-id in the email

[maboloshi]

installation-id is not equal to user id. https://github.com/actions/create-github-app-token/pull/105#issuecomment-1955720302 The user id can be obtained by requesting https://api.github.com/users/$AppSlug[bot].

Here's how my bot signature is generated.

function set_dco_signature {
    if [[ $TOKEN == ghp_* ]]; then
        # https://github.blog/2021-04-05-behind-githubs-new-authentication-token-formats/
        # What starts with 'ghp_' is the GitHub personal access token

        response=$(curl -s -H "Authorization: token $TOKEN" "$GITHUB_URL/user")
    elif [[ $APP_SLUG ]]; then
        CommitBot=$APP_SLUG
    else
        CommitBot="github-actions"
    fi

    if [[ $CommitBot ]]; then
        response=$(curl -s -H "Authorization: token $TOKEN" "$GITHUB_URL/users/$CommitBot\[bot\]")
    fi

    CommitBot=$(echo "$response" | jq -r '.login')
    id=$(echo "$response" | jq -r '.id')
    echo "Signed-off-by: $CommitBot <$id+$CommitBot@users.noreply.github.com>"
}

[vleon1a]

installation-id is not equal to user id. #105 (comment) The user id can be obtained by requesting https://api.github.com/users/$AppSlug[bot].

Here's how my bot signature is generated.

function set_dco_signature {
    if [[ $TOKEN == ghp_* ]]; then
        # https://github.blog/2021-04-05-behind-githubs-new-authentication-token-formats/
        # What starts with 'ghp_' is the GitHub personal access token

        response=$(curl -s -H "Authorization: token $TOKEN" "$GITHUB_URL/user")
    elif [[ $APP_SLUG ]]; then
        CommitBot=$APP_SLUG
    else
        CommitBot="github-actions"
    fi

    if [[ $CommitBot ]]; then
        response=$(curl -s -H "Authorization: token $TOKEN" "$GITHUB_URL/users/$CommitBot\[bot\]")
    fi

    CommitBot=$(echo "$response" | jq -r '.login')
    id=$(echo "$response" | jq -r '.id')
    echo "Signed-off-by: $CommitBot <$id+$CommitBot@users.noreply.github.com>"
}

Exactly, which is why I think it makes sense to return it as an output to the action 😄

[gr2m]

I agree it would be convenient to add the app's user ID to the output, but it would require an additional request that most users won't need.

I suggest we document that approach first in the README, with an extra step to retrieve the user ID using https://github.com/octokit/request-action/ or something similar.

[vleon1a]

I agree it would be convenient to add the app's user ID to the output, but it would require an additional request that most users won't need.

I suggest we document that approach first in the README, with an extra step to retrieve the user ID using https://github.com/octokit/request-action/ or something similar.

Maybe we could add an additional input to request it?

[maboloshi]

@vleon1a You can try this.

      - name: Generate GitHub App Token
        id: generate-token
        uses: actions/create-github-app-token@c8f55efbd427e7465d6da1106e7979bc8aaee856 # v1.10.1
        with:
          app-id: ${{ secrets.SEMANTIC_RELEASE_APP_ID }}
          private-key: ${{ secrets.SEMANTIC_RELEASE_PRIVATE_KEY }}
      - name: Get bot Id
        id: get-bot-id
        uses: octokit/request-action@v2
        with:
          route: GET /users/${{ steps.generate-token.outputs.app-slug }}[bot]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: GitHub Release
        env:
          GITHUB_TOKEN: ${{ steps.generate-token.outputs.token }}
          GIT_AUTHOR_NAME: ${{ steps.generate-token.outputs.app-slug }}[bot]
          GIT_AUTHOR_EMAIL: ${{ fromJson(steps.get-bot-id.outputs.data).id }}+${{ steps.generate-token.outputs.app-slug }}[bot]@users.noreply.github.com
          GIT_COMMITTER_NAME: ${{ steps.generate-token.outputs.app-slug }}[bot]
          GIT_COMMITTER_EMAIL: ${{ fromJson(steps.get-bot-id.outputs.data).id }}+${{ steps.generate-token.outputs.app-slug }}[bot]@users.noreply.github.com
        run: npx semantic-release

[vleon1a]

@vleon1a You can try this.

      - name: Generate GitHub App Token
        id: generate-token
        uses: actions/create-github-app-token@c8f55efbd427e7465d6da1106e7979bc8aaee856 # v1.10.1
        with:
          app-id: ${{ secrets.SEMANTIC_RELEASE_APP_ID }}
          private-key: ${{ secrets.SEMANTIC_RELEASE_PRIVATE_KEY }}
      - name: Get bot Id
        id: get-bot-id
        uses: octokit/request-action@v2
        with:
          route: GET /users/${{ steps.generate-token.outputs.app-slug }}[bot]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: GitHub Release
        env:
          GITHUB_TOKEN: ${{ steps.generate-token.outputs.token }}
          GIT_AUTHOR_NAME: ${{ steps.generate-token.outputs.app-slug }}[bot]
          GIT_AUTHOR_EMAIL: ${{ fromJson(steps.get-bot-id.outputs.data).id }}+${{ steps.generate-token.outputs.app-slug }}[bot]@users.noreply.github.com
          GIT_COMMITTER_NAME: ${{ steps.generate-token.outputs.app-slug }}[bot]
          GIT_COMMITTER_EMAIL: ${{ fromJson(steps.get-bot-id.outputs.data).id }}+${{ steps.generate-token.outputs.app-slug }}[bot]@users.noreply.github.com
        run: npx semantic-release

Yes, that would work indeed, but my initial thought was that as the action returns metadata already it would make sense, even if it requires one additional call. If not possible I will adapt in that way.

[gr2m]

Yes, that would work indeed, but my initial thought was that as the action returns metadata already it would make sense, even if it requires one additional call. If not possible I will adapt in that way.

Actions are composable, I'd rather document how to get what you want in our README as it is a common request, but not add more code to this action

I think @maboloshi suggestion above is great on how to get the app user ID.

By the way, for @semantic-release specifically, I don't think it's necessary unless you use the git plugin. I'm co-maintain semantic-release and use it a lot, I never needed to set any of theGIT_ environment variables. But feel free to open an issue over at @semantic-release as it's off-topic for this discussion.

[vleon1a]

Yes, that would work indeed, but my initial thought was that as the action returns metadata already it would make sense, even if it requires one additional call. If not possible I will adapt in that way.

Actions are composable, I'd rather document how to get what you want in our README as it is a common request, but not add more code to this action

I think @maboloshi suggestion above is great on how to get the app user ID.

By the way, for @semantic-release specifically, I don't think it's necessary unless you use the git plugin. I'm co-maintain semantic-release and use it a lot, I never needed to set any of theGIT_ environment variables. But feel free to open an issue over at @semantic-release as it's off-topic for this discussion.

Thanks, I can open a PR to mention this to the readme file then. And I am indeed using the git plugin for my semantic release configuration, hence the need for environment variables!

[maboloshi]

It looks like #145 is already doing this, probably with a preference for the gh command.

[vleon1a]

Closing as the readme has been updated in #145