Description of problem: When forking a project in copr, the output produces a second Build ID for each included build and the according entries in the build list in the fork. The Build IDs are all empty, looking at the directory contents. The falsly generated Build ID of the build contains all info from the original Build ID where it forks from but there is no directory created nor the files copied into the fork. The Build ID always has a lower ID than the second Build ID which actually contains the fork contents. So, after forking a project one always has to manually delete the Builds in the Build list which are non-existent to clean up the Build list to mirror the acutally present builds Version-Release number of selected component (if applicable): How reproducible: Create an empty copr project and fork another project into the empty project Steps to Reproduce: 1. 2. 3. Actual results: Two build IDs are generated for each Build of the original during forking, one with a lower number and that is non-existent. If you go into the build and the chroot you get an error message. If you go into the higher ID of the build in the project forked into, you can traverse up the directories and see that there is only one build id directory of the build present. Expected results: Additional info:
Thank you for the report, > The Build IDs are all empty, looking at the directory contents. do you have an example link?
I've opened a Pull Request that addresses this issue. https://pagure.io/copr/copr/pull-request/1444
Per IRC ping: > <loise_> praiskup: thanks that someone took action on the double creation of forked builds - but it is solved the wrong way :) > <loise_> praiskup: it doesn't work, someone took the *lower* build number to fork into an existing project and then the build artefacts are not copied, so it is a blind copy with no effect on actually copying anything :) > <loise_> praiskup: so instead of solving the problem it is actually worse than before - you can't actually fork into an existing copr project at all any more (which is a really annoying thing updating a repo) This has not been fixed in production yet (only git master upstream). The behavior you observe is probably a different bug (new bug report will be appreciated).
Actually, that was a false alarm that I thought was happening at some point, but wasn't. The issue itself is still the same way as reported originally, so no new bug report needed.