Workflow manual input step: how do I use it the right way?

[Martin d'Anjou]

I think I am using the Workflow manual input step incorrectly. I must misunderstand the problem it solves.

My pipeline has several steps:
1) compiler phase 1 and test (1 hour)
3) manually decide whether to stop or continue to step 4
4) compiler phase 2 and more tests (2 to 4 hours)
5) manually decide whether to stop or continue to step 6
6) deploy to dev
7) manually decide whether to stop or continue to step 8
8) deploy to production

Only a few, out of thousands, make it to production. When I use the Workflow plugin with the manual input step, it leaves builds with balls blinking waiting for user input. Also, pausing eventually blocks all execution slots. With thousands of builds, this can't be right.

This cannot be how the manual input is intended to work. How do people do manual build steps that depend on upstream jobs?

Thanks,
Martin

[James Nord]

if you are using all the executors then you are using the "input" step inside a node block.

Use it outside of a node block and it won't consume any executors (and IIRC as of recently it won't consume any threads either!)

If you need access to your files (which may be true if you are keeping the node active) use the stash/unstash command (1.10) to store and retrieve them.

SO that will fix your executor issue - the next issue is leaving 1000+ builds waiting for user input....

It really depends on your flow - do you want to wait 14 days for that one build in dev to to be authorised to production?

If not - then wrap the input with a timeout - which will then abort the build if no one wants to promote it.

Do you have multiple dev environments?  if not then you can also kill the waiting for ok to promote to production when a later build is promoted to dev.

[Martin d'Anjou]

if you are using all the executors then you are using the "input" step inside a node block.

Thanks. Putting the input step outside of a node block releases the execution slot. But the blue ball keep blinking on the project page, that will be quite annoying with lots of builds pending a decision to continue down the pipeline.

It really depends on your flow - do you want to wait 14 days for that one build in dev to to be authorised to production?

Yes it happens, rarely, but it happens. I want to avoid process decisions that limit what developers might need to do.

Is there a way to stop the blue balls from blinking on the project page, and display something less annoying instead?
Is there a way to show the "Paused for input" message on the build page rather than on a sub-page?

Thanks,
Martin

[James Nord]

not that I know of but both sound like reasonable RFEs - and if you feel like writing some code I'm sure the PRs will get some love.

[Guest]

Even if I'm using it outside the node block it still consumes some resources on master - am I right? I think so, because I'm unable to start second pipeline instance while the first one is waiting for input. So my question is: would it possible to completely stop pipeline execution (serialize to disk and forget let's say) during waiting for input and resume it only when someone clicks? Something similar works in other CI solutions and if I remember correctly old-styled jenkins pipelines also had this feature.

[Antonio Muñiz]

On Thu, May 5, 2016 at 3:45 PM, Guest <lumo...@gmail.com> wrote:

because I'm unable to start second pipeline instance while the first one is waiting for input

It should not be the behavior, unless you explicitly disabled "Execute concurrent builds if necessary".

--

Antonio Muñiz

Software Engineer
CloudBees, Inc.