Plans for this action given the new official `actions/create-github-app-token`?

[MPV]

The readme in this repo links to an old version of the docs:
https://web.archive.org/web/20230115194214/https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions#example-workflow-authenticating-with-a-github-app

...which have now been updated here:
https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions#example-workflow-authenticating-with-a-github-app

...to use the new official action:

• https://github.com/actions/create-github-app-token

...which now in a few weeks seems to have gained the equivalent feature set (and hopefully stays maintained/improved).

Just thought I'd raise this issue to surface any thoughts on how these two actions relate to each other.

There also seems to be a bunch of others in the same field:

• Research learnings and ideas from similar GitHub Actions actions/create-github-app-token#42

[gr2m]

👋🏼 just wanted to say hi, I'm one of the maintainers of the new https://github.com/actions/create-github-app-token. Our main motivation to create an official action is to not use a 3rd party action for this sensitive functionality as part of our internal efforts to make GitHub itself more secure. I'm also a maintainer of @octokit and wanted us to create an action that doesn't use third party dependencies, as changes are hard to review for consumers given that the final code is a compiled single file that consists of the action's code as well as all their dependencies.

I'm happy to help contribute best practices back to this action, I see that you already implemented the invalidation of a the token in a post step.

Thank you so much for creating this great action, I've been using it for a long time across many projects ❤️

Let me know if you have any further questions

[tibdex]

Thanks for your comment Gregor. It would be nice to bring the official action to feature parity with this one. I could then deprecate/archive this one. These inputs are not yet supported by the official action. Do you plan on adding support for them?

changes are hard to review for consumers given that the final code is a compiled single file that consists of the action's code as well as all their dependencies.

The docs also mentions using ncc to compile the action's code to a single file.

Besides, I explained in #41 why the way this action is published provides the best supply chain security. Other approaches such as "commit the node_modules and package-lock.json" are worst since, if I was an attacker, I could have manually changed some file under node_modules and it would be hard for any reader to realize it. @gr2m, do you agree?

I'm happy to help contribute best practices back to this action

Which best practices do you have in mind?

[gr2m]

These inputs are not yet supported by the official action. Do you plan on adding support for them?

The permissions for sure, that's been planned since the beginning. I can't say about the other ones yet. Could you point us to why you implemented the retrieval mode? I assume it's to make creating the installation access token more efficient without the need to lookup the installation first, but I'm not yet sure if it's worth adding the complexity

Besides, I explained in #41 why the way this action is published provides the best supply chain security

I agree it's the right approach, we also compile to a single file for actions/create-github-app-token. We just try to limit the amount of code that gets compiled into it by using lower-level @octokit packages, and ideally no 3rd party components in the dependency tree at all, but we are not quite there yet.

Which best practices do you have in mind?

None that you haven't addressed in your action yet I think

[tibdex]

Could you point us to why you implemented the retrieval mode?

Yes, it was asked in the tickets closed by #84.

[gr2m]

Thank you for sharing the context!

Unless I miss something, we already implemented what was requested in #76 by only providing with.owner (example)

Was there a separate request for implementing the retrieval using installation ID?

[tibdex]

Unless I miss something, we already implemented what was requested in #76 by only providing with.owner (example)

Yes, it looks like the same feature with a different API.

Was there a separate request for implementing the retrieval using installation ID?

Yes: #17.

I believe it's the last feature that differentiates this action from yours.

[gr2m]

Yes: #17.

Hmm that sounds like they want to create a JWT instead of an installation access token?

I believe it's the last feature that differentiate this action from yours.

Yes I think so. I think we'll sit this one out and wait for people to come up with their use cases before we go down that path though.

Thanks again for sharing all these insights, much appreciated

[cliffchapmanrbx]

I just commented in the other action that my PR #43 adding support for alternate GITHUB_API_URL values is a blocker for us to migrate.