coervivek michaelneale WDYT of having a blueocean-github plugin that contains all the github specific REST endpoints and UI for the creation flow? See the description above.

cc vivek (wrong vivek jamesdumay!).

I think this makes sense at a high level, not mudding up blue ocean with github specifics. This is assuming that there needs to be github specifics that aren't in the github/ plugins that are pre-existing and exposed via a generic blue ocean api?

jamesdumay

Keeping github specific functionality in it's own plugin is good. However not sure what's the use case for these?

• Exposes a REST API to test a access token against a github API endpoint
• Testing returns the list of oauth scopes that the credentials will allow and the users name

We do not want to give the access token to the client (github tokens live forever), basically its never supposed to escape the plugin backend. So why expose it via REST API?

vivek I think the idea is to test it when the user provides it, perhaps it is not described as clearly as it should be.

michaelneale I see, so we are talking about Personal Access Token, typically used in case of 2FA. Even in that case, why does UI needs users scopes? Maybe there is some UI flow that I am missing. Regardless, I think if the idea is (specially in case of 2FA enabled on github) and UI asking user to give manually create a Personal Access Token at github and creates a credential in jenkins (sort of secret text) and give this secret text id to blueocean UI. This can then be passed over to backend to use this secret to talk to github. Or there is something else is discussed here and I am missing it?

No that is right. The way you work now with github branch source is you create a personal token and use it. That token needs to have the right level of access for things to work (github has an api to validate that).

In the future, a one-click integration could automatically generate this long lived oauth token, but that doesn't work yet unless you have a fixed url (ie a saas)

vivek hmm, we may have to test the access key before we create the credentials.

For example:

1. User enters in the access key
2. We check that the key is valid and has the required scopes
   • If the key does not have the required scopes we let the user know which scopes are missing and they go back to Step #1
3. Now that the access key is validated we can create the credentials safely
4. Proceed with creating the pipeline