Mark task as failed if artifacts upload is attempted, but fails
Categories
(Taskcluster :: Workers, defect)
Tracking
(Not tracked)
People
(Reporter: mhentges, Unassigned)
Details
Sourced from Dustin's comment on Github.
It sounds like it's possible for artifact uploads to fail, but the task is still marked as a success when that happens, which isn't ideal behaviour, since it can break downstream tasks.
Comment 1•6 years ago
|
||
Can you provide an example where you saw this? We'll want to check which of the two existing artifact APIs was used..
Comment 2•6 years ago
|
||
Is this Bug 1512733 - Docker Worker reports green even when an artifact of type "file" is not found. ?
Comment 3•6 years ago
|
||
Nope, slightly different -- I provided the contrast in the linked comment:
The issue you have identified seems to be around artifacts for which uploads are begun but never finished. That's a bug, and might even be worth fixing depending on the details (it might not be worth fixing if the fix is complex, as there is work on a new approach to artifacts that involves a new "object service").
Comment 4•6 years ago
|
||
Oh, now that I see the linked task in the github thread:
https://taskcluster-web.netlify.com/tasks/QON0-jDdSaKHlqEW81oogA/runs/0
the artifacts are
https://queue.taskcluster.net/v1/task/QON0-jDdSaKHlqEW81oogA/runs/0/artifacts/public/app-klar-x86-nightly-unsigned.apk
{
"reason": "file-missing-on-worker",
"message": "Artifact "public/app-klar-x86-nightly-unsigned.apk" not found at "/opt/repository/app/build/outputs/apk/klarX86/nightly/app-klar-x86-nightly-unsigned.apk""
}
with HTTP status 424.
So yes, this is a duplicate of bug 1512733.
Assignee | ||
Updated•6 years ago
|
Description
•