Research learnings and ideas from similar GitHub Actions

[gr2m]

Follow up to #39 (comment).

In preparation for #3 and #4 it might make sense to learn from similar actions.

• tibdex/github-app-token
• peter-murray/workflow-application-token-action
• getsentry/action-github-app-token
• microsoftgraph/get-app-token
• wow-actions/use-app-token
• navikt/github-app-token-generator
• mercari/github-app-token-generator
• jnwng/github-app-installation-token-action
• And many more...

[gr2m]

I looked through them again and two things that stood out for me

• should we consider two parameters in order to set the installation for the token: either the name of the owner login or an installation id? I think an owner login should suffice, but if the installation ID is known then we would save a request.
• Proxy settings: https://github.com/peter-murray/workflow-application-token-action#proxy

There is also a lot to learn in terms of documentation, in particular how to register a GitHub App.

[Moser-ss]

I was trying to migrate from the action peter-murray/workflow-application-token-action to this one, and I noticed this action does not support the private-key input as a Base64 encoded string.

Does it make sense to create an issue for that? I don't have any problem opening a PR to support that use case.

Also, an issue we have with the action peter-murray/workflow-application-token-action that didn't have any internal retry mechanism; maybe we can improve that in this action.

I will be happy to start working in some PRs to improve this action

[gr2m]

private-key input as a Base64 encoded string

what is the use case? Maybe the decoding a base64 string could be done in a separate step before using this action?

didn't have any internal retry mechanism

For retries, @octokit has the retry plugin, it's rather heavy though, due to its dependency on bottleneck. We try to keep the code of this action, including its dependencies, to a minimum. It might make sense to implement a custom retry in this case particular case

[Moser-ss]

So joining these two use cases, I have experienced failures getting the token from a GitHub app, so we start to use an extra action to retry Wandalen/wretry.action, then we have the issue with the input that is broken with multiline strings like the format of the PEM files, so we had to do encode the private key with base64.

Also, it is annoying to keep copying and pasting the ugly syntax of an action that retries another action.
So, if this action itself has the internal retry, I don't even need the base64 encoding.

So, does it make sense to implement a retry logic inside the action?

[gr2m]

the input that is broken with multiline strings like the format of the PEM files, so we had to do encode the private key with base64

would replacing line breaks with "\n" work? That's what we do in environments where multi-line environment variables are not supported

if this action itself has the internal retry, I don't even need the base64 encoding

Perfect 👍🏼

I agree we should implement a retry, could you please file a separate issue for it?

[newbloke82]

I would like to try and help implement the proxy support. Getting this working from self-hosted runners behind a corporate proxy is important for my project.
I'm interested in changing the behaviour of the app to use GITHUB_API_URL as a default but allow for an override to deal with the use case of calling GHES from GHEC. This would also support GHES to GHES requests. This is useful for services like renovatebot/dependabot that need to lookup dependencies in private repos:
https://docs.github.com/en/code-security/dependabot/working-with-dependabot/configuring-access-to-private-registries-for-dependabot
https://docs.renovatebot.com/getting-started/private-packages/

[gr2m]

@newbloke82 makes sense, thank you for laying it out! Can you please first file an issue? I think tibdex/github-app-token is implementing proxy support the way you suggest, right? See https://github.com/tibdex/github-app-token/blob/3eb77c7243b85c65e84acfa93fdbac02fb6bd532/action.yml#L8-L10

[vleon1a]

private-key input as a Base64 encoded string

what is the use case? Maybe the decoding a base64 string could be done in a separate step before using this action?

In my case we migrate from an action expecting the private key to be Base64 encoded. One solution is to create a new secret with the plain private key, but i just tried to test how we could decode it on the fly.
It does work, but it's quite the overhead in my opinion, especially to ensure the masking is done and multiline storage is working fine:

- name: Decode private key
  id: decoding
  run: |
    private_key=$(echo "${{ secrets.SEMANTIC_RELEASE_PRIVATE_KEY }}" | base64 -d) &> /dev/null
    while read -r line;
    do
      echo "::add-mask::${line}"
    done <<< "$private_key"
    echo 'private-key<<EOF' >> "$GITHUB_OUTPUT"
    echo "$private_key" >> "$GITHUB_OUTPUT"
    echo 'EOF' >> "$GITHUB_OUTPUT"
- name: Generate GitHub App Token
  id: generate-token
  uses: actions/create-github-app-token@31c86eb3b33c9b601a1f60f98dcbfd1d70f379b4 # v1.10.3
  with:
    app-id: ${{ secrets.SEMANTIC_RELEASE_APP_ID }}
    private-key: ${{ steps.decoding.outputs.private-key }}

The output is a bit ugly, but at least it's concealed:

Run actions/create-github-app-token@31c86eb3b33c9b601a1f60f98dcbfd1d70f379b4
  with:
    app-id: ***
    private-key: ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
  ***
    github-api-url: https://api.github.com/
owner and repositories not set, creating token for the current repository ("my-repo")

---

would replacing line breaks with "\n" work? That's what we do in environments where multi-line environment variables are not supported

This works also, and is more clean than the previous one:

- name: Decode private key
  id: decoding
  run: |
    private_key=$(echo "${{ secrets.SEMANTIC_RELEASE_PRIVATE_KEY }}" | base64 -d | awk 'BEGIN {ORS="\\n"} {print}' | head -c -2) &> /dev/null
    echo "::add-mask::$private_key"
    echo "private-key=$private_key" >> "$GITHUB_OUTPUT"
- name: Generate GitHub App Token
  id: generate-token
  uses: actions/create-github-app-token@31c86eb3b33c9b601a1f60f98dcbfd1d70f379b4 # v1.10.3
  with:
    app-id: ${{ secrets.SEMANTIC_RELEASE_APP_ID }}
    private-key: ${{ steps.decoding.outputs.private-key }}

---

If the action is not planned to handle the private key being potentially encoded in Base64, I think we should add this in the readme, to avoid people leaking their private keys (I can open a PR)