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. 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@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
_______________________________________________
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
