Closed Bug 1233604 Opened 4 years ago Closed 4 years ago
Make decision task more explicit about what tasks were recognized and what really got run
This is an open-ended request to make the decision task less opaque. Bug 1146025 would accomplish similar things. I pushed with incorrect task quoting, and got a D with no sub-tasks: https://treeherder.mozilla.org/#/jobs?repo=try&revision=f784f6d7dd91 It took a wild guess to correct the task quoting; after that, I got a better result: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3fa59aab48fc Some diagnostics and logging of what happened would go a long way.
Bug 1146025 was implemented. For example: https://public-artifacts.taskcluster.net/S-_zyHYzREKmEI5Ti7Khzg/0/public/graph.json Does this change help? Is there another feature we should consider right now?
(In reply to Selena Deckelmann :selenamarie :selena from comment #1) > Bug 1146025 was implemented. For example: > https://public-artifacts.taskcluster.net/S-_zyHYzREKmEI5Ti7Khzg/0/public/ > graph.json > > Does this change help? Is there another feature we should consider right now? I agree that the JSON helps, but I can't really judge whether this is less opaque without seeing the TH push. I think that's what really matters, since that's the interface devs will use to investigate why things aren't happening. Based on that JSON artifact alone, it's going to be tricky to determine why a task *didn't* run. It will confirm that nothing ran, sure; but it's completely opaque.
Isn't this more of making it obvious when invalid syntax was used on try? > try: -b o -p android-api-11-frontend vs > try: -b o -p 'android-api-11-frontend' The try parser should have failed.
Bug 1258497 makes this quite a bit clearer, with lots of artifacts to dig into the details with.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.