| Summary: | sys-apps/portage: don't clean files when test-fail-continue feature is used and test fails | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Pacho Ramos <pacho> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | arsen, erikdenstore+gbugs, james.al.stevenson, kingjon3377, mgorny, rhill, sam, telans |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 912975 | ||
|
Description
Pacho Ramos
2009-04-06 22:26:15 UTC
As a workaround, you can enable PORT_LOGDIR. Thanks for the tip! actually, it would be nice if test-fail-continue would keep the entire build dir around on failures so any logs the testsuite might have generated don't get blown away. (In reply to comment #3) > actually, it would be nice if test-fail-continue would keep the entire build > dir around on failures so any logs the testsuite might have generated don't get > blown away. > Yes, also, after reading make.conf page, I saw the following: fail-clean Clean up temporary files after a build failure. This is particularly useful if you have PORTAGE_TMPDIR on tmpfs. If this feature is enabled, you probably also want to enable PORT_LOGDIR in order to save the build log. Both the ebuild(1) command and the noclean feature cause the fail-clean feature to be automatically disabled. then, from my point of view, portage should simply keep files if any ebuild phase fails and, if somebody disagrees with that behavior, he can use fail-clean. It seems also more consistent than current behavior as, but default, any failure will end with files preserved Thanks Thanks a lot (In reply to Ryan Hill from comment #3) > actually, it would be nice if test-fail-continue would keep the entire build > dir around on failures so any logs the testsuite might have generated don't > get blown away. Adapting to this as I just needed to re-run ebuild ... test to get some files were errors are logged for reporting to upstream ;) I think I've actually changed my mind about this. With the number of packages that fail tests these days, this would fill up a tmpdir pretty fast... I guess it depends on how often we look for failures and the kind of tmpdir we have. Ideally, we could configure that behavior. I wondered about using "noclean" FEATURE but I didn't as that one would really waste a lot of space as it would keep files for even packages that don't fail tests at all. Other main advantage of preserving files with test-fail-continue is for cases where different tests fail depending on we updating the package or re-emerging it. For example, I reviewed this yesterday due the long standing rhythmbox failing tests: 1. I read about the failures at /var/log/summary.log 2. I look at its build.log and I see I need to provide a tests.log file that is generated at build dir. 3. I re-emerge the package with ebuild rhythmbox... test to get them 4. The set of failing tests is different (only 1 test failing instead of 4) 5. I need to downgrade it and repeat it. If I would have got the tests.log file from start it would have been much easier to directly report the issue to upstream :) This would also be useful when tests are prone to fail but don't always fail, for example with evolution-data-server and its dbus related tests The test-fail-continue code is buried down inside the EbuildPhase class, but its the EbuildBuild class that needs to be aware of the test failure so that it can tell the EbuildMerge class not to clean the build dir. We could handle this by having the EbuildBuild class pass a callback down to EbuildPhase, so that it can be notified of the test failure and take appropriate action. Would that make it possible to suppress the typical "agh, phase failed" wall of error text when test-fail-continue is used? If so I fully endorse it and will be filing a follow-up enhancement req. :) (In reply to Ryan Hill from comment #9) > Would that make it possible to suppress the typical "agh, phase failed" wall > of error text when test-fail-continue is used? If so I fully endorse it and > will be filing a follow-up enhancement req. :) That's an entirely separate issue. Anyway, yeah, go ahead and file an enhancement request. What you want is some conditional code inside die, so that it suppresses the usual die message when die is called during src_test and FEATURES=test-fail-continue is enabled. (In reply to Zac Medico from comment #8) > The test-fail-continue code is buried down inside the EbuildPhase class, but > its the EbuildBuild class that needs to be aware of the test failure so that > it can tell the EbuildMerge class not to clean the build dir. > > We could handle this by having the EbuildBuild class pass a callback down to > EbuildPhase, so that it can be notified of the test failure and take > appropriate action. So, as a hack, maybe we can pass this information "out-of-band" by creating a file ".portage_tests_failed" somewhere in the build directory, then check for it later? |
