Bug 1304012
Summary: | Can't see logs on failed build | ||
---|---|---|---|
Product: | [Community] Copr | Reporter: | Tom "spot" Callaway <tcallawa> |
Component: | frontend | Assignee: | clime |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | clime, dave.love, holcapek, jkadlcik, praiskup, sergio |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-03-29 12:22:18 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tom "spot" Callaway
2016-02-02 16:48:07 UTC
The builds ...got deleted. Failed builds are pruned every day, which is too often and will be subject to change. Related to: Bug 1304695 I think you'll find that there were never any files written unless they're always being removed within seconds of failure. (In reply to Tom "spot" Callaway from comment #0) > https://copr.fedorainfracloud.org/coprs/spot/chromium/build/156327/ > > All the links are 404... the links are : https://copr-be.cloud.fedoraproject.org/results/spot/chromium/fedora-22-x86_64/00156327-native_client shouldn't be copr.fedorainfracloud.org ? I also have some 404 but on my case , for example: https://copr.fedorainfracloud.org/coprs/sergiomb/buildsforF21/package/azureus/ this link https://copr.fedorainfracloud.org/coprs//buildsforF21/build/147223/ gives 404 because the correct is : https://copr.fedorainfracloud.org/coprs/sergiomb/buildsforF21/build/146116/ url don't have miss my username. in https://copr.fedorainfracloud.org/coprs/sergiomb/buildsforF21/monitor/ links are correct. BTW monitor webpage, reports azureus as failed when it was succeeded (other bug) In reply to Jens Petersen from comment #3) > I think you'll find that there were never any files written unless they're > always being removed within seconds of failure. That is the case for SRPM import failures (into dist-git). If that happens, no directory for build results is even created and the link to the build results should be disabled in UI (so no 404s). The only way, that I currently know of, to get empty white page from copr-be machine with just 404 error is for the build directory to get deleted by the prunning script. (In reply to Sergio Monteiro Basto from comment #4) > (In reply to Tom "spot" Callaway from comment #0) > > https://copr.fedorainfracloud.org/coprs/spot/chromium/build/156327/ > > > > All the links are 404... > > the links are : > https://copr-be.cloud.fedoraproject.org/results/spot/chromium/fedora-22- > x86_64/00156327-native_client > > shouldn't be copr.fedorainfracloud.org ? No, the build results are stored on a separate copr-be machine. > I also have some 404 but on my case , for example: > https://copr.fedorainfracloud.org/coprs/sergiomb/buildsforF21/package/ > azureus/ > > this link > https://copr.fedorainfracloud.org/coprs//buildsforF21/build/147223/ > gives 404 > > because the correct is : > https://copr.fedorainfracloud.org/coprs/sergiomb/buildsforF21/build/146116/ > > url don't have miss my username. This is a separate issue. It has been fixed by fce4438bba. > in https://copr.fedorainfracloud.org/coprs/sergiomb/buildsforF21/monitor/ > links are correct. > > BTW monitor webpage, reports azureus as failed when it was succeeded (other > bug) Please, look into the list of COPR bugs and report this one if it has not been reported yet. Fixed by a5c93116e2. *** Bug 1304695 has been marked as a duplicate of this bug. *** *** Bug 1306183 has been marked as a duplicate of this bug. *** Code with this fix is currently deployed on testing server. You can test it before it will be deployed to production. Please see: http://copr-fe-dev.cloud.fedoraproject.org Copr production machines were upgraded to version containing a fix to this issue. If you are not satisfied with provided solution, please feel free to reopen this. |