[CDRIVER-3497] Environment setup failure in debian-package-build and rpm-package-build should be a system failure Created: 19/Jan/20 Updated: 28/Jan/20 Resolved: 28/Jan/20 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | tests |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Kevin Albertson | Assignee: | Kevin Albertson |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
If the debian-package-build/rpm-package-build tasks fail to create a chroot, that should show up as a system failure (purple) instead of a task failure (red) so it is easier to determine whether the task was broken by code changes or environment changes. The evergreen docs suggest this could be done by creating a file on failure to create a chroot environment, and having a subsequent "system" task check if that file exists. |
| Comments |
| Comment by Kevin Albertson [ 28/Jan/20 ] |
|
Since transient failures that don't require changes are rare, let's keep this as a test failure. If transient failures do become more of a concern, we could add retries within the task. |
| Comment by Roberto Sanchez [ 21/Jan/20 ] |
|
I have had similar thoughts in the past, but I am concerned that this may mask legitimate failures. For instance, the debian-package-build task includes a call to debootstrap, which prepares the build environment. That step might fail if a package is uninstallable (this may happen as a transitory condition during a library migration or the chroot creation attempt is made after the package index is updated but before the mirror server has fully synchronized), in which case it should be considered a system failure. On the other hand, the chroot creation step might also fail if a package we are requesting be installed in the chroot is unavailable (e.g., because the package name has changed or has been dropped from Debian). That seems like it should be considered a proper failure; although it is not a result of a code change that was made, it requires a change to the Evergreen build helper scripts to address the failure. It is not clear how to reliably distinguish between the two conditions, as it requires grokking the output of the debootstrap command. Similar issues are involved with the rpm-package-build task. That seems to leave two possibilities:
|