196
Option to allow failures in Fan-In/Out Workflow
under review
B
Brandon Page
The requires tag in workflows really limits what is possible. Requires makes a lot of sense for the deployment scenario used to demo it, but waiting for a group of jobs to complete (pass or fail) should be an option.
Scenario: Setup -> Run multiple sets of tests in parallel -> Combine test results/coverage results/artifacts and report to PR
That scenario above isn’t possible because if a single test fails in any of the jobs running in parallel the the fan-in step won’t run.
CCI-I-344
Activity
Newest
Oldest
V
Vikram Ambre
Liya Ai Hi, I know that this is in the works, however is there any timeline for this?
Octavious Williams
New
Anton Matveiev
Hi. This is a desired feature for my company. Use case: collect test results from multiple jobs that run in parallel. If some of the jobs fail we want to collect the test results.
T
Test User
Liya Ai, Hello, any updates?
Liya Ai
Test User: Please see response from our PM below: We've been investigating this in conjunction with a related feature to enable filtering of jobs within a workflow. Part of the reason this has been slow is that we try to be very careful with changes to the config syntax. When making the changes we need to maintain backwards compatibility so builds aren't broken without change. At the same time, once we make changes to the syntax they can be hard to back out since some customers start using them and removing those changes might make those configs invalid. We have some ideas we are refining, but given the impacts mentioned above, this might take some time to do the right way. - it was a bit hidden so re-posting here in case you also missed it like I did
T
Test User
Liya Ai: Thank you, we are looking forward to this functionality.
M
Mike Lay
Here is a related feature request that specifically requests the important use-case of running on failure as opposed to always.
Trevor Jones
This would be great for those that use sonarqube as well.
run parallel jobs and then aggregate everything before the sonar upload. otherwise everything has to run in a single job since you can't append more data to an existing sonar analysis.
Trevor Jones
real world hit of this for my team is that sonar never gets our UI test coverage data since we run sonar in the job with unit tests and linting.
L
Liya Ai
under review
R
Robert Cooper
Liya Ai: Hi Liya, any update on this? It's been "Under Review" for ~9months now...
Liya Ai
Robert Cooper: Hi Robert! Thanks for asking - Under review actually means that we are considering this idea but it is not yet prioritized (if you go to the changelog you can see a list of all the definitions). Often time there is a conflicting product decision or technical discovery we are working out to move ideas to planned. I will bump this to our team and see if there are any updates.
Salil Subbakrishna
Robert Cooper: We've been investigating this in conjunction with a related feature to enable filtering of jobs within a workflow. Part of the reason this has been slow is that we try to be very careful with changes to the config syntax. When making the changes we need to maintain backwards compatibility so builds aren't broken without change. At the same time, once we make changes to the syntax they can be hard to back out since some customers start using them and removing those changes might make those configs invalid. We have some ideas we are refining, but given the impacts mentioned above, this might take some time to do the right way.
A
Ari Bolton
+1 -- my company has the exact same use case as in the description
Amo Wu
vote
L
Lucian Stoicescu
Use case for my company would be saving screenshots to cloud if the test jobs generates them - this would only be needed if the test job fails (or else there are no screenshots of the failures). We cannot have the upload be part of the test job for various reasons so a require_failed would be perfect
Load More
→