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

Form to capture user input when pipeline is waiting for user input

    XMLWordPrintable

Details

    • pacific, 1.0-b05/b-06

    Description

      In Scope

      • Pipeline graph, activity list, branch list and result screen needs to communicate somehow that the pipeline is blocked and waiting for input
      • Developer will need some way of providing the input (dialog with a form?) and a way of triggering the input form.

      Notes
      A pipeline can block for user input at any point.

      The input can take the form of Yes/No to continue or fail the current run.
      It can also ask for some piece of input from a user (which may be a choice, a password or other things).

      Currently the Jenkins 2.0 stage view shows only the Yes/No case, but ideally blue ocean will be able to show the other forms of approval.

      This form will be used both when the user clicks on the "waiting for input" card, or from the railroad.

      (this is both a design task, but an API will likely be needed for this).

      Attachments

        1. Input Form.png
          Input Form.png
          121 kB
        2. screenshot-1.png
          screenshot-1.png
          7 kB
        3. Successful result.png
          Successful result.png
          88 kB

        Issue Links

          Activity

            michaelneale Michael Neale added a comment -

            A list of the types of input:

            michaelneale Michael Neale added a comment - A list of the types of input:
            michaelneale Michael Neale added a comment -

            vpandey does the current REST api in blue ocean cater to blocking for input, and submitting user input when a pipeline is waiting?

            michaelneale Michael Neale added a comment - vpandey does the current REST api in blue ocean cater to blocking for input, and submitting user input when a pipeline is waiting?
            michaelneale Michael Neale added a comment - - edited

            jdumay

            You can see there are a few options.
            In classic jenkins log/console screen, when it is waiting for input it contains a hyperlink to a form that looks like the following (depending on input type chosen):


            The current stage viewer in Jenkins only allows Yes/No answers. We need to decide what the scope is that we target in Blue Ocean. Some of these options can get quite complex, and involve capturing lots of data potentially from users.

            michaelneale Michael Neale added a comment - - edited jdumay You can see there are a few options. In classic jenkins log/console screen, when it is waiting for input it contains a hyperlink to a form that looks like the following (depending on input type chosen): The current stage viewer in Jenkins only allows Yes/No answers. We need to decide what the scope is that we target in Blue Ocean. Some of these options can get quite complex, and involve capturing lots of data potentially from users.
            jamesdumay James Dumay added a comment -

            mneale one of the plugin devs we will be talking to this week might be interested in building something like this out. He's been working on a form of parameterised builds where they can have dependant fields.

            jamesdumay James Dumay added a comment - mneale one of the plugin devs we will be talking to this week might be interested in building something like this out. He's been working on a form of parameterised builds where they can have dependant fields.
            michaelneale Michael Neale added a comment -

            jdumay yes this would be quite similar. Some of the field options include things like "capturing credentials" or a choice parameter, password, even plugins can contribute. I am not sure what is commonly used (as far as I know really just ok/cancel, maybe capturing a reason why it is rejected).

            What is popular is enforcing that only those with certain permissions can allow something to proceed or not, that is often asked for (this is more an API thing than a UI thing, as the required role/permission is defined in the Jenkinsfile).

            This is fairly similar to parametrised build (which is something that doesn't really exist with multibranch today as it doens't make sense).

            michaelneale Michael Neale added a comment - jdumay yes this would be quite similar. Some of the field options include things like "capturing credentials" or a choice parameter, password, even plugins can contribute. I am not sure what is commonly used (as far as I know really just ok/cancel, maybe capturing a reason why it is rejected). What is popular is enforcing that only those with certain permissions can allow something to proceed or not, that is often asked for (this is more an API thing than a UI thing, as the required role/permission is defined in the Jenkinsfile). This is fairly similar to parametrised build (which is something that doesn't really exist with multibranch today as it doens't make sense).

            jamesdumay your screenshot show groups (Development, QA, Business) in the graph. Is that an existing feature, or is that something drafted for this issue?

            raphink Raphaël PINSON added a comment - jamesdumay your screenshot show groups (Development, QA, Business) in the graph. Is that an existing feature, or is that something drafted for this issue?
            jamesdumay James Dumay added a comment -

            raphink it's just conceptual and happened to include the play icon for which I am considering for the input step (so it's unrelated). Is it something of interest to you?

            jamesdumay James Dumay added a comment - raphink it's just conceptual and happened to include the play icon for which I am considering for the input step (so it's unrelated). Is it something of interest to you?
            raphink Raphaël PINSON added a comment - - edited

            jamesdumay Definitely, that could be very useful. Also, I see there's steps inside parallel branches in your graph (in the QA part). This would normally be achived using stages, but stages are not displayed in parallel branches, are strongly advised against in parallel branches apparently. Is there another way to achieve this?

            raphink Raphaël PINSON added a comment - - edited jamesdumay Definitely, that could be very useful. Also, I see there's steps inside parallel branches in your graph (in the QA part). This would normally be achived using stages, but stages are not displayed in parallel branches, are strongly advised against in parallel branches apparently. Is there another way to achieve this?
            jamesdumay James Dumay added a comment -

            raphink there's no way to visualise what you have there today but I'd be really happy to chat with you about your use case. Hit me on email jdumay@cloudbees.com

            jamesdumay James Dumay added a comment - raphink there's no way to visualise what you have there today but I'd be really happy to chat with you about your use case. Hit me on email jdumay@cloudbees.com
            brody Brody Maclean added a comment -

            Mockup of input needed

            Zeplin link https://zpl.io/20DP3w

            brody Brody Maclean added a comment - Mockup of input needed Zeplin link https://zpl.io/20DP3w
            michaelneale Michael Neale added a comment -

            (also can we keep comments on topic, I can't delete the comments/screen shot that isn't relevant)

            michaelneale Michael Neale added a comment - (also can we keep comments on topic, I can't delete the comments/screen shot that isn't relevant)
            michaelneale Michael Neale added a comment -

            Visual design is ready to go.

            michaelneale Michael Neale added a comment - Visual design is ready to go.
            vivek Vivek Pandey added a comment -

            jamesdumay michaelneale Credentials parameter visualization is different in classic where it shows dropdown box of available options, whereas this visual design shows it as username and password field. See the image below from classic, where it gives option to user to add a new credential as well, if you click Add, it takes you to Credential form input. I assume we are going to show list of available credentials? Which is pretty much a drop down choice box then.

            vivek Vivek Pandey added a comment - jamesdumay michaelneale Credentials parameter visualization is different in classic where it shows dropdown box of available options, whereas this visual design shows it as username and password field. See the image below from classic, where it gives option to user to add a new credential as well, if you click Add, it takes you to Credential form input. I assume we are going to show list of available credentials? Which is pretty much a drop down choice box then.
            michaelneale Michael Neale added a comment -

            vivek jamesdumay perhaps this should be a drop down for credentials... is thi sthe case where it asks for a credential when it is asking for input? (we could start with a credential id text field if we needs to, or a dropdown like creation)

            michaelneale Michael Neale added a comment - vivek jamesdumay perhaps this should be a drop down for credentials... is thi sthe case where it asks for a credential when it is asking for input? (we could start with a credential id text field if we needs to, or a dropdown like creation)
            jamesdumay James Dumay added a comment -

            michaelneale vivek we should reuse what we are building in creation IMO

            jamesdumay James Dumay added a comment - michaelneale vivek we should reuse what we are building in creation IMO
            vivek Vivek Pandey added a comment -

            In creation flow its limited to SSH type credential only (for git SCM), not a generic one. In this case are we planning a drop down of SSH type credentials? In case of GitHub, we are not going to show any credential drop down or creation credential.

            If we plan to reuse it credential UI components then it might need some change as in case of credential input, its going to be usernamepassword type credentials? Also UI needs to call credential creation API (separate from input POST call to submit input form), then populate choice dropdown to have the new credential listed. Atleast thats what is on classic. Basically creation of credential is going to make things complex. Maybe to start with we only show credential drop down for user to chose from?

            vivek Vivek Pandey added a comment - In creation flow its limited to SSH type credential only (for git SCM), not a generic one. In this case are we planning a drop down of SSH type credentials? In case of GitHub, we are not going to show any credential drop down or creation credential. If we plan to reuse it credential UI components then it might need some change as in case of credential input, its going to be usernamepassword type credentials? Also UI needs to call credential creation API (separate from input POST call to submit input form), then populate choice dropdown to have the new credential listed. Atleast thats what is on classic. Basically creation of credential is going to make things complex. Maybe to start with we only show credential drop down for user to chose from?

            People

              michaelneale Michael Neale
              jamesdumay James Dumay
              Votes:
              2 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: