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 <cl...@fedoraproject.org > <mailto:cl...@fedoraproject.org>> wrote: > > On Tue, 14 Apr 2020 at 12:05, Vít Ondruch <vondr...@redhat.com > <mailto: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. > > > > 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. Vít > I think it is an unwanted situation. > Some pollution of lookaside seems inevitable. But it happens even now > without possibility to take uploaded file back. > > > > > > > > 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 > <mailto:devel@lists.fedoraproject.org> > > To unsubscribe send an email to > devel-le...@lists.fedoraproject.org > <mailto: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 > <mailto:devel@lists.fedoraproject.org> > > To unsubscribe send an email to > devel-le...@lists.fedoraproject.org > <mailto: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 > <mailto:devel@lists.fedoraproject.org> > To unsubscribe send an email to > devel-le...@lists.fedoraproject.org > <mailto: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
