Repository navigation
OAuth as alternative to Personal Access Token for Github API access #932
Description
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
Activity
babblebey commentedon Oct 4, 2024
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 commentedon Oct 4, 2024
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 commentedon 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 commentedon 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)IvanJosipovic commentedon Apr 2, 2025
I want to use semantic-release in Azure DevOps Pipelines which provides a OAuth token for GitHub.
gr2m commentedon Apr 3, 2025
I don't see a reason why you shouldn't be able to use a GitHub OAuth token for semantic-release's GitHub plugin. Did you try it?
I'm not sure I follow, do you mean the client_id and client_secret? These credential cannot be used as a replacement for an access token
As in: implement a flow where a user receives a message with link they would need to click to authenticate? That's out of scope for this plugin, I create a dedicated plugin for that.