On Mon, 20 Apr 2020 at 14:24, Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > > Dne 20. 04. 20 v 13:52 Ondrej Nosek napsal(a): > > > > On Mon, Apr 20, 2020 at 11:42 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: >> >> >> Dne 20. 04. 20 v 1:31 Ondrej Nosek napsal(a): >> >> Thanks for answers, comment in the text follows. >> >> On Tue, Apr 14, 2020 at 12:16 PM clime <clime@xxxxxxxxxxxxxxxxx> wrote: >>> >>> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch <vondruch@xxxxxxxxxx> wrote: >>> > >>> > >>> > Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a): >>> > >>> > TLDR: Is $SUBJ function reasonable to implement in fedpkg? >>> > >>> > Hi, >>> > >>> > some time ago, fedpkg issue tracker got a request [1] for method, that allows direct builds. That means without sending srpms via "--srpm" argument. Currently, user's changes can be built: >>> > >>> > fedpkg scratch-build --srpm >>> > >>> > This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg sends just (git) hash id to koji. But fedpkg needs modification to send a right hash id for user changes. Additionally, koji doesn't allow building hash ids from forked repos. >>> > >>> > >>> > Even if this was possible, that would also mean that the sources have to be uploaded into look-a-side cache. Then it very much depend what is the content of the PR. If I am building Ruby nightly snapshots, I don't think it is fair to pollute look-a-side cache with them and I am afraid this is not the only case. I wish we had a way to override the look-a-side cache somehow .... >>> >>> If I understand correctly, this would have to be done, if sources >>> changed only, right? I.e. if there is a change just in patch or a spec >>> file, the sources could be fetched from the main project. >> >> >> Yes, just sources (and eventually other binary files) are uploaded to lookaside cache. In the case of specfile and patches, there is no lookaside modification. Fork shares the same lookaside cache with the main project. >> >>> >>> >>> Should there be a possibility to upload sources for a fork that would >>> then be moved to the main project when the pull request is merged? >> >> >> That sounds complicated to me and maybe it is not worth the intended result. Or I didn't find the right (easier) approach. ... New sources (and binaries) in fork need to be saved somewhere. >> - In a parallel lookaside (for forks) >> - In git repo (omitting lookaside) >> During the merge, some trigger would move the sources to the main lookaside. This creates a new file hash(es). And it would result in another commit done by a trigger. >> >> >> Why it should create new hash(es)? If the fork/PR contains an updated sources file (and it really should), then there is no reason for new commit. > > > Oh. In my last post, I wanted to say, that no commit is needed if you are using main lookaside. Just in case you have parallel lookaside or other storage, you have to upload sources from your alternative storage to main lookaside and it would result in the extra commit. > But I looked at code how lookaside works internally. Hash is computed locally and the upload path (except the host) should be the same for both lookasides. So I realized that during merge, only download the sources from parallel lookaside and upload it to the main lookaside would work. Without extra commit. But is it a win? This might bring other problems. Timeouts when some large source is processed? > Parallel lookaside is intended to not mess the main lookaside. So I think the parallel lookaside should be cleaned somehow. > > > It should be cleaned as often as the stalled PRs? I know we don't have infrastructure for this, but it would be logical answer to your question. Imho, you need to think also about repos from which pull requests are never created and that can have uploaded sources. > > > Vít > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
