-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAuth as alternative to Personal Access Token for Github API access #932
Comments
Hi @sparr, thanks for creating this issue. I'd like to start by noting that (this is my opinion, might not reflect the direction of the project in the long run) semantic-release is only (and currently remains) a CLI tool/app that runs in an environment that expects persistent access to a user’s account; and runs automatically at that considering the main reason for the project is to remove humans as much as possible from release process. Now, the one use case I can see for this feature is when semantic-release is ran manually from the terminal, it could start an OAuth flow when it finds no token in the environment it runs. But, running semantic-release like even though it's possible isn't something we encourage. We instead want you to configure semantic-release to run in your CI/CD pipelines automatically and only after all the tests in the CI build passes. I'd like to get the thoughts from others here Cc: @semantic-release/maintainers @semantic-release/github |
Hi @sparr It's also important to ask; What exactly you're trying to build?? i.e. your use case for this requested functionality, this can help us understand better if you can share..😉 |
OAuth credentials could be used in a CI environment as well; they can be long lived and persistent although that's not the usual way to issue them. My use case is as you mentioned, running in a local terminal. I want to be able to perform the steps of https://github.com/fgardt/factorio-mod-template/blob/0d9d2b4b7ca14d1370d35d24f71c5912e00f0d06/.github/workflows/release.yml locally on certain occasions / situations. |
For that case it would also be possible to read the npm token out of your user .npmrc and could theoretically also read a github token out of the credentials file the gh cli uses (if you're using it). It would take less work to accomplish that than supporting OAuth. Another workaround you could use right away would be to make a script that does |
New feature motivation
I want to run semantic-release in an environment where I already have valid OAuth credentials for GitHub that I could use without generating and using a Personal Access Token if that feature was available here. Or to do so in an environment where I could use a browser to grant OAuth access interactively.
New feature description
Everywhere a github token is used for API access, oauth credentials would need to be usable instead. This includes conditional validation and verification.
Optionally a workflow for interactive authentication (like
gh auth login
does)New feature implementation
No response
The text was updated successfully, but these errors were encountered: