-
Task
-
Resolution: Done
-
Critical
-
-
pacific, 1.0-b05/b-06
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).
- blocks
-
JENKINS-38494 User can see the input form on an input step (UI)
-
- Resolved
-
-
-
- Resolved
-
[JENKINS-35899] Form to capture user input when pipeline is waiting for user input
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?
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 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 
(also can we keep comments on topic, I can't delete the comments/screen shot that isn't relevant)
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 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 vivek we should reuse what we are building in creation IMO
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?
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?