Wait and block pipeline step » different state for pipeline

[jufemaiz]

Hi guys, loving Buildkite as we move a whole bunch of things from alternatives.

One thing that frustrates me a little from a UX perspective is the impact of "Wait and block pipeline" steps on the state of a pipeline.

At the moment, there's essentially four states for a step in a pipeline (as far as I can tell):

• Waiting
• Actioning
• Failed
• Passed

When a "Wait and block pipeline" step is added and the previous step(s) have completed as Passed, Buildkite indicates that the Pipeline has passed, which is invalid as it's actually in a fifth state which is not based purely on the last state of the Pipeline steps to have actioned – "Blocked" (or something similar).

This is also reflected in API feedback (Hipchat hooks, emails).

Email notification of Pipeline state - Passed (in this case [Fixed] because it was previously failing):

Hipchat notifications:

It would be great to see a "Blocked" state introduced (seems to be understood by BK as the "unblocking" event is triggered and surfaced) as a feedback loop for people who can unblock the pipeline so that it may continue and truly be fixed.

Adding this so that others can contribute, based on previous conversation via Twitter @ https://twitter.com/buildkite/status/723313317012332544

[toolmantim]

Thanks for the feedback! We're working on exactly this. Stay tuned 🔜

[jufemaiz]

@toolmantim cheers mate! Thought it was good to actually use your feedback repo for this (in case others had similar requirements) :)

[gtirloni]

@jufemaiz I think that's the same thing I see on GitHub. The PR gets marked with a green checkmark but the build hasn't actually finished. When scanning the list of PRs, that could be misleading.

[jufemaiz]

@gtirloni yeah, it's not in the BK UI (it's a pause symbol) but it propagates outwards as a tick rather than maintaining an "in progress". Part of that I guess is the different use cases. @toolmantim and @lox could probably provide more insight.

[NorseGaud]

Any update on this? Block steps should not default to "passed" as this causes the PR reviewer to think it passed all tests when they review a community PR.

[toolmantim]

For people using GitHub, there’s a setting in your pipeline’s GitHub settings called “Blocked builds show in GitHub as…” which you can use to control this behavior.

[huguesb]

For people using GitHub, there’s a setting in your pipeline’s GitHub settings called “Blocked builds show in GitHub as…” which you can use to control this behavior.

What about people not using github? Could that setting be made available more broadly via the yaml pipeline definition? Right now it seems the only way around this is to artificially keep the pipeline going with a busy loop that ties up an agent, which is really wasteful and makes input steps largely useless