Optional build jobs
B
Borut Tomazin
Similar to the conversation going on here I would like to have the option to define optional workflow jobs that would not affect the status of the test suite. Imagine I have a flow that runs the tests, but it only does the deployment of specific branches. I would like to add optional jobs that can be triggered manually (this is already supported using
hold
requirement) and also would not affect the outcome result of the tests - if all tests passed this flow should be marked as green regardless of the optional jobs state.CCI-I-433
O
Owen Ashurst
This would be really useful since in our use case, I wanted a job to deploy to our development environment automatically on master, but would not run automatically on branches but still be visible for people to manually deploy their branch if they need to test something in an environment.At the minute, branch filtering is limited in which I've found it 'hides' the jobs that do not match the filter which hid my deploy-to-dev job because it was on a branch that was not master which was no good. This is quite a limitation.
A
Aaron Buchanan
We're using the gating concept for our jobs and are seeing everything represented as ON_HOLD, because the approval steps to promote / deploy will be triggered infrequently. We'd expect to see a successful status if all but the approval jobs succeeded.
V
Vinny Thanh
I believe this would be useful for workflows containing deployment jobs. Not every commit / workflow kicked off on master branch should necessarily deploy. Using an approval job as a gate, people would like to pick and choose which workflows / commits to approve for deployment without the Workflow badge showing up as "Failed".
E.g., if all the tests pass, but we don't choose to deploy, it should still show up as "Passed"
A
Andrew Lavery
Personally, I would love something that let me do something like this:
A -> B -> on success -> -> C \ on failure -> HOLD /
That way we could have a deploy staging -> test staging -> check if prod DB version matches staging DB version -> if yes, deploy prod - if no, wait for a hold (and then deploy prod)
N
Nathan Dintenfass
Another way we think about this is to provide another status other than Pass or Fail that can be a "Warn" or other intermediate state that would not cause the Workflow or downstream jobs to be skipped. We have also thought about making it easier to continue to running even after a failure, which would be another way to solve the kind of flows you are describing. Both features are under consideration but not yet committed.