Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-42791

Developer should be asked for their Github token when loading the editor

XMLWordPrintable

    • Blue Ocean 1.0-rc3, Blue Ocean 1.1, Blue Ocean 1.2-beta1, Blue Ocean 1.2-beta2, Blue Ocean 1.2-beta3, Blue Ocean 1.2-beta4, Blue Ocean 1.2

      Improvement on roadmap

      This improvement is on the Blue Ocean project roadmap. Check the roadmap page for updates.

      Context
      A Github token is required to read and write the Jenkinsfile. In the situation where a second user tries to edit a pipeline and they have never provided their Github token, the editor should prompt them for their token. They could also be asked to provide their credential if the one stored is invalid.

      Scope

      • When loading the editor we should check that the token they have associated with the user is valid and has the correct scopes to write to the repository.
        • If they cannot write to the repository they should see a dialog:
          • Title: Permission denied
          • Description: You do not have the required permissions to edit this Pipeline.
          • Button: "Go back"
      • If there is no token, we ask for the token (as per the mockups below)
        • Title: "Connect to Github"
        • Description: "Jenkins needs an access key to read and write to the repository <i>$repositoryName</i>"
        • Buttons
          • Connect
          • "Cancel" - takes you back whence you came

      Notes
      Keep in mind that we will have to make the same flow work for when the user does not have SSH credentials for Git and Bitbucket. Does not need to be resolved this effort but just something to think about as you are developing.

      Mockups

          [JENKINS-42791] Developer should be asked for their Github token when loading the editor

          Cliff Meyers added a comment -

          jamesdumay brody a few questions:

          1. Would this dialog look identical for GitHub Enterprise users?
          2. How do we envision the Git-based flow looking? In current Git Creation, there is a dropdown menu to choose an existing credential and a button alongside, which when pressed pops up a dialog to create a new credential. We probably wouldn't want that exact UX here, as it would create the dreaded "modal on top of modal" UX. Perhaps a mock-up that shows the Git variant of this UX would be a good idea so I can at least think get a sense of how to unify things later.
          3. How significantly would the need to change if we walk back the use of org folders?

          Cliff Meyers added a comment - jamesdumay brody a few questions: Would this dialog look identical for GitHub Enterprise users? How do we envision the Git-based flow looking? In current Git Creation, there is a dropdown menu to choose an existing credential and a button alongside, which when pressed pops up a dialog to create a new credential. We probably wouldn't want that exact UX here, as it would create the dreaded "modal on top of modal" UX. Perhaps a mock-up that shows the Git variant of this UX would be a good idea so I can at least think get a sense of how to unify things later. How significantly would the need to change if we walk back the use of org folders?

          James Dumay added a comment -

          cliffmeyers

          1. It would be identical
          2. I've prepared examples of these here
          3. I think we just drop the "Auto-discover" from the creation flow and then everything else remains the same.

          James Dumay added a comment - cliffmeyers It would be identical I've prepared examples of these here I think we just drop the "Auto-discover" from the creation flow and then everything else remains the same.

          Cliff Meyers added a comment -

          jamesdumay thanks, #2 is actually quite helpful.

          Cliff Meyers added a comment - jamesdumay thanks, #2 is actually quite helpful.

          Cliff Meyers added a comment -

          jamesdumay I'd say the other open question is how to handle potential reuse of a credential. For Git users, odds are they will be working in many repos but use the credential. Seems there are three possibilities:

          1. Just make them enter the credential each time, which will be tedious and lead to duplication of the same secret in many different Jenkins credentials,
          2. Allow them to view a list of existing credentials and pick one (basically a Dropdown menu)
          3. Build some intelligence into the backend to check if any of the existing credentials are valid to access the pipeline's SCM provider (fancy but maybe not feasible dev effort)

          Cliff Meyers added a comment - jamesdumay I'd say the other open question is how to handle potential reuse of a credential. For Git users, odds are they will be working in many repos but use the credential. Seems there are three possibilities: Just make them enter the credential each time, which will be tedious and lead to duplication of the same secret in many different Jenkins credentials, Allow them to view a list of existing credentials and pick one (basically a Dropdown menu) Build some intelligence into the backend to check if any of the existing credentials are valid to access the pipeline's SCM provider (fancy but maybe not feasible dev effort)

          James Dumay added a comment - - edited

          cliffmeyers

          1. We are moving to a model where there is a public/private SSH generated by Jenkins on a per user basis that the user needs to register the public key with their Git server. We wont be asking them to enter any credentials.
          2. There is no dropdown menu for selecting credentials
          3. This point is moot.

          James Dumay added a comment - - edited cliffmeyers We are moving to a model where there is a public/private SSH generated by Jenkins on a per user basis that the user needs to register the public key with their Git server. We wont be asking them to enter any credentials. There is no dropdown menu for selecting credentials This point is moot.

          Cliff Meyers added a comment -

          jamesdumay after discussing with Keith last week we identified a hole in our service API. While we can validate and create the the credential, we need an API to associate that user's credential with the GitHub org folder. It looks like the code to do so may be here:

          https://github.com/jenkinsci/blueocean-plugin/blob/master/blueocean-github-pipeline/src/main/java/io/jenkins/blueocean/blueocean_github_pipeline/GithubPipelineCreateRequest.java#L128

          @vivek do you have any thoughts on this?

          Cliff Meyers added a comment - jamesdumay after discussing with Keith last week we identified a hole in our service API. While we can validate and create the the credential, we need an API to associate that user's credential with the GitHub org folder. It looks like the code to do so may be here: https://github.com/jenkinsci/blueocean-plugin/blob/master/blueocean-github-pipeline/src/main/java/io/jenkins/blueocean/blueocean_github_pipeline/GithubPipelineCreateRequest.java#L128 @ vivek do you have any thoughts on this?

          Michael Neale added a comment -

          cliffmeyers vivek When you open the creation flow and click github - it will check the user can access it and validate the token. If not - it will ask the user. This happens as the credential is stored against user, not org folder or anything. So can look at how creation works, and try to make it work in a similar fashion? 

           

          (github enterprise will be slightly more complicated, as it depends what pipeline they are editing for what GHE server etc). 

          Michael Neale added a comment - cliffmeyers vivek When you open the creation flow and click github - it will check the user can access it and validate the token. If not - it will ask the user. This happens as the credential is stored against user, not org folder or anything. So can look at how creation works, and try to make it work in a similar fashion?    (github enterprise will be slightly more complicated, as it depends what pipeline they are editing for what GHE server etc). 

          SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Cliff Meyers
          Path:
          Jenkinsfile
          PULL_REQUEST_TEMPLATE
          README.md
          src/main/js/EditorPage.jsx
          src/main/js/PipelineEditorLink.jsx
          http://jenkins-ci.org/commit/blueocean-pipeline-editor-plugin/49a802926f9e67e27c7a0ffb2a762ba8c0de4c31
          Log:
          Merge branch 'master' into story/JENKINS-42791-editor-prompt-github-token

          1. Conflicts:
          2. src/main/js/EditorPage.jsx

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Cliff Meyers Path: Jenkinsfile PULL_REQUEST_TEMPLATE README.md src/main/js/EditorPage.jsx src/main/js/PipelineEditorLink.jsx http://jenkins-ci.org/commit/blueocean-pipeline-editor-plugin/49a802926f9e67e27c7a0ffb2a762ba8c0de4c31 Log: Merge branch 'master' into story/ JENKINS-42791 -editor-prompt-github-token Conflicts: src/main/js/EditorPage.jsx

          SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Cliff Meyers
          Path:
          pom.xml
          src/main/js/EditorPage.jsx
          src/main/js/SaveApi.js
          http://jenkins-ci.org/commit/blueocean-pipeline-editor-plugin/5a9d0c228a2a6bb7ca2ab033daae88e78ec9c40e
          Log:
          Merge branch 'master' into story/JENKINS-42791-editor-prompt-github-token

          1. Conflicts:
          2. src/main/js/EditorPage.jsx
          3. src/main/js/SaveApi.js

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Cliff Meyers Path: pom.xml src/main/js/EditorPage.jsx src/main/js/SaveApi.js http://jenkins-ci.org/commit/blueocean-pipeline-editor-plugin/5a9d0c228a2a6bb7ca2ab033daae88e78ec9c40e Log: Merge branch 'master' into story/ JENKINS-42791 -editor-prompt-github-token Conflicts: src/main/js/EditorPage.jsx src/main/js/SaveApi.js

          Cliff Meyers added a comment -

          PR's https://github.com/jenkinsci/blueocean-plugin/pull/1318 and https://github.com/jenkinsci/blueocean-pipeline-editor-plugin/pull/45 should hopefully be the last PR's to get this wrapped up.

          Cliff Meyers added a comment - PR's https://github.com/jenkinsci/blueocean-plugin/pull/1318 and https://github.com/jenkinsci/blueocean-pipeline-editor-plugin/pull/45 should hopefully be the last PR's to get this wrapped up.

            cliffmeyers Cliff Meyers
            jamesdumay James Dumay
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: