CircleCI Ideas

Optional build jobs

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.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • May 25 2018
  • Taking votes
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    12 Feb 06:05pm

    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.  

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    21 Aug, 2019 05:52pm

    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"

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    15 Jan, 2019 07:03pm

    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)

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    25 May, 2018 07:21am

    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.