Re: Koji: Could the initial side tag repo be copied from parent (to avoid worflow delays)?
On 06. 04. 23 21:51, Kevin Fenzi wrote: On Thu, Apr 06, 2023 at 08:21:36AM +0200, Miro Hrončok wrote: Hello, When using custom side tags like this: $ fedpkg request-side-tag $ fedpkg chain-build --target f38-build-side-... ... One of the obstacles is that the initial waitrepo for the job takes a lot of time, (e.g. 10+ minutes). That is not comfortable for the package maintainer -- it's faster to use buildroot overrides. I wonder if the initial createrepo could be skipped entirely by symlinking / copying / using the already available repository from the base (parent) tag. That could make this workflow more attractive. The sidetag plugin code is in upstream koji. This sounds like a great RFE for koji then? I don't know why it's not done that way, there might be a reason or might be an oversight, but please file a RFE on it? :) https://pagure.io/koji/issue/3808 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Koji: Could the initial side tag repo be copied from parent (to avoid worflow delays)?
On Thu, Apr 06, 2023 at 08:21:36AM +0200, Miro Hrončok wrote: > Hello, > > When using custom side tags like this: > > $ fedpkg request-side-tag > $ fedpkg chain-build --target f38-build-side-... ... > > One of the obstacles is that the initial waitrepo for the job takes a lot of > time, (e.g. 10+ minutes). That is not comfortable for the package maintainer > -- it's faster to use buildroot overrides. > > I wonder if the initial createrepo could be skipped entirely by symlinking / > copying / using the already available repository from the base (parent) tag. > > That could make this workflow more attractive. The sidetag plugin code is in upstream koji. This sounds like a great RFE for koji then? I don't know why it's not done that way, there might be a reason or might be an oversight, but please file a RFE on it? :) Side note: I recall when normal newrepos took like 40-45min (and we had a lot less packages then), so 10min seems nice to me. But I agree if it could be made mostly instant that would be great for this case. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Koji: Could the initial side tag repo be copied from parent (to avoid worflow delays)?
Hello, When using custom side tags like this: $ fedpkg request-side-tag $ fedpkg chain-build --target f38-build-side-... ... One of the obstacles is that the initial waitrepo for the job takes a lot of time, (e.g. 10+ minutes). That is not comfortable for the package maintainer -- it's faster to use buildroot overrides. I wonder if the initial createrepo could be skipped entirely by symlinking / copying / using the already available repository from the base (parent) tag. That could make this workflow more attractive. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
