Description of problem:
If someone updates a task without tagging it expecting it will be picked up by scheduled job, all running jobs using that task will break.
The same applies to problem with missing rpms: even if RPM is re-uploaded, it is not picked up, but this is not as bad as first problem.
This is a regression reintroducing the problem with repo metadata (Bug 599424) but this time the problem can not be solved on lab-machine by cleaning metadata as the recipe's repo is not rebuilt.
Possible solutions:
- copying all RPMs to extra directory
- extra space requirements
- rebuilding repositories
- and we are back where we were before Bug 606242
- hardlinking RPMs to extra directory
Hard-linking seems the way to go.
+ May be we need a way to refresh the repo to preserve "update task while job is running" feature. RFE?
Version-Release number of selected component (if applicable):
0.5.54
How reproducible:
100%
Steps to Reproduce:
1. schedule a job
2. when it is running change and upload new rpm without tagging it with make tag
Actual results:
- the task can not run: see the ...unexpected... file for the updated task.
Expected results:
- updated task should run after metadata are rebuilt.
Possibly another variation on this same issue. When a test is updated and jobs are already in the running state you may get failures while trying to download the new test rpm.
See Job: https://beaker.engineering.redhat.com/recipes/108933#task1198023
and T:1198026
This should be solved with bug 835367, we will be hardlinking RPMs into per-recipe repos.
*** This bug has been marked as a duplicate of bug 835367 ***