On Mon, Apr 20, 2020 at 11:42 AM Vít Ondruch <vondr...@redhat.com> 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 <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. > > >> >> 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. Periodically? Based on age? How should I recognize if the file is safe to delete? Do users always use forked projects as temporary so they wouldn't mind that unmerged source is deleted from lookaside after one month? > 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 >> > 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 >
_______________________________________________ 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
