OAuth as alternative to Personal Access Token for Github API access

[sparr]

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

[babblebey]

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]

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]

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]

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]

I want to use semantic-release in Azure DevOps Pipelines which provides a OAuth token for GitHub.

[gr2m]

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?

Everywhere a github token is used for API access, oauth credentials would need to be usable instead. This includes conditional validation and verification.

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

Optionally a workflow for interactive authentication (like gh auth login does)

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.