Skip to content
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

Open
sparr opened this issue Sep 26, 2024 · 4 comments
Open

OAuth as alternative to Personal Access Token for Github API access #932

sparr opened this issue Sep 26, 2024 · 4 comments

Comments

@sparr
Copy link

sparr commented Sep 26, 2024

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

@travi travi transferred this issue from semantic-release/semantic-release Sep 26, 2024
@babblebey
Copy link
Member

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

@babblebey
Copy link
Member

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

@sparr
Copy link
Author

sparr commented Oct 4, 2024

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.

@jedwards1211
Copy link
Contributor

jedwards1211 commented Oct 4, 2024

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 CI=1 NPM_TOKEN=... GH_TOKEN=... ./node_modules/.bin/semantic-release (someone correct me if I'm missing anything)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants