On Mon, 20 Apr 2020 at 01:33, Ondrej Nosek <ono...@redhat.com> wrote: > > Thanks for answers, comment in the text follows. > > On Tue, Apr 14, 2020 at 12:16 PM clime <cl...@fedoraproject.org> wrote: >> >> On Tue, 14 Apr 2020 at 12:05, Vít Ondruch <vondr...@redhat.com> 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.
Cool! > >> >> >> 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) Yes, this is what I was thinking about. > - 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). I don't think it creates new file hashes. I mean checksums of the files should stay the same as the content stays the same, no? Maybe I am omitting something. > And it would result in another commit done by a trigger. I think it is an > unwanted situation. I think an additional commit should not be needed due to above. > Some pollution of lookaside seems inevitable. But it happens even now without > possibility to take uploaded file back. Yes, that's true. --- I think the solution with fork-specific sources is mainly problematic. > >> >> > >> > >> > Vít >> > >> > >> > The question to the community. Is reasonable to implement this way of >> > building scratches? --srpm argument would still work as previously. >> > >> > There is a suggested PR for this here: [2]. It is not completed yet. >> > >> > Risks: >> > * approach could confuse users. Users are used to work with fedpkg >> > differently. >> > * koji would have to allow these builds >> > * more code complexity; currently there is a way how to reach your result >> > even without this function >> > >> > Thanks >> > Ondrej >> > >> > [1] https://pagure.io/fedpkg/issue/282 >> > [2] https://pagure.io/fedpkg/pull-request/390 >> > >> > _______________________________________________ >> > 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 >> > >> > _______________________________________________ >> > 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 >> _______________________________________________ >> 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 > > _______________________________________________ > 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 _______________________________________________ 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
