gracefully handle expired artifacts while building in artifact mode
Categories
(Firefox Build System :: General, defect, P3)
Tracking
(Not tracked)
People
(Reporter: aryx, Unassigned)
Details
Attachments
(1 file)
353.91 KB,
image/png
|
Details |
User nan_ reported their attempt to build ESR 102 had failed. See screenshot for log. The mentioned task ID points to a push from April 30 and the target.common.tests.tar.gz
for that push is not found the building process tries to download is not found.
This is an artifact build. Could it handle the situation more gracefully, e.g. generate the missing artifact?
Comment 1•2 years ago
|
||
Interestingly, the task that happened with is https://firefox-ci-tc.services.mozilla.com/tasks/MnM2L3EsTQGCVXYw2d0fRA, and its artifacts are ... not expired. There's nothing in the task definition that says those artifacts should have expired before next year, and nothing in the corresponding task on mozilla-central that says these artifacts should expire earlier in newer tasks of the same type. So, something must have cleaned up those artifacts (but not all of them because e.g. target.zip is there).
Marco, do you know anything about that?
Could it handle the situation more gracefully, e.g. generate the missing artifact?
Generating the missing artifact would involve... doing a non-artifact build. While we could consider doing so automatically, it would also be an large inconvenience if someone asks for a build that should end in a minute or less, and ends up being opted-in to dedicate an hour of their time for that build...
Note that these kinds of errors are not supposed to happen. That is, the artifact code assumes the complete set of artifacts for the given build exists. The assumption was broken by some of the artifacts not being there in actuality.
![]() |
Reporter | |
Comment 2•2 years ago
|
||
emaydeck and I discussed this, the artifact got removed in https://mozilla-hub.atlassian.net/browse/OPST-701
Updated•2 years ago
|
Updated•2 years ago
|
Description
•