#1886 Build-results-chroot dir contents are affected by opening the dir during the build run
Closed: Fixed 3 years ago by praiskup. Opened 3 years ago by ksurma.

There is some quantum behavior in copr when observing the build destroys the easy access to build artifacts.
When you run a build in copr and want to take a look at artifacts while the build still runs, it's possible. It however affects how the artifacts will be displayed later.
In the linked build, I've taken a look at the files when the build was in state "running" by clicking on chroot fedora-rawhide-x86_64. There was only one file at the time.
The build ended successfully, yet the results were not populated under this link. There is still the one file that was in the moment of first check.
To get the full build logs, one has to go a level up in directory structure and find the exact build number there. For mass actions and many repetitious builds of the same package this can be tedious.
If you don't observe the results while running, the results are populated under the chroot link correctly, like in the other reference build.


Metadata Update from @praiskup:
- Issue assigned to praiskup

3 years ago

Thank you for the question!

Indeed, there's caching done in AWS's CDN. You can re-try that you'll see the
updated directory after some time (when caches are invalidated).
The problem you observe though has no effect on the rpm repository itself,
DNF always sees the up2date repo.

This was asked several times before, so I'm adding a FAQ item here:
https://pagure.io/copr/copr/pull-request/1887

Log in to comment on this ticket.

Metadata
Related Pull Requests
  • #1887 Merged 3 years ago