For me it is: 99% "I want to check if local changes build" - fedpkg scratch-build --srpm 1% "Something changed in Rawhide and I want to see if X still builds" - fedpkg scratch-build
I didn't know "fedpkg build" has a scratch option, TIL. Cheers, Chris On Mon, 16 Jan 2023 at 10:52, Daniel P. Berrangé <berra...@redhat.com> wrote: > On Mon, Jan 16, 2023 at 09:56:31AM +0200, Otto Liljalaakso wrote: > > Hello everybody, > > > > I would like to gather different use cases for the 'fedpkg scratch-build' > > command. > > > > Currently, this is exactly the same as 'fedpkg build --scratch', meaning > > that is performs a scratch build of the pushed head of the current > branch. > > At least in my workflow, I only do scratch builds before pushing, to > ensure > > that what I am about to push builds correctly in Koji. Because if this, I > > never use the default form. Instead, I always specify 'fedpkg > scratch-build > > --srpm', so that the srpm to build from is locally generated from the > local > > working directory. > > > > What I would like to do is to submit a pull request to either fedpkg or > > rpkg, making that the default. It is a single line code change, not > counting > > changes to documentation and code comments. > > > > Doing a scratch build from the pushed contents would still be possible by > > either a) using 'fedpkg build --scratch' or b) checking out the remote > head > > and then issuing 'fedpkg scratch-build'. > > > > Above change seems like a clear improvement to me, making the most used > > option the default. But I have noticed that workflows differ wildly > between > > packagers, so before submitting any code for review, I would like to > hear if > > somebody regularly uses the default form 'fedpkg scratch-build' and > thinks > > it currently does the right thing. > > Yep, testing non-pushed content is the primary reason for doing a > scratch-build. So 95% of the time I'll use "fedpkg scratch-build --srpm" > on non-pushed content. Very occassionally I'll do a scratch build > with pushed content, if testing compat with the latest build root > contents. > > Probably 70% of the time I would often also add "--arch x86_64" to > avoid burning CPU time across all the Fedora arch builders for a plain > smoketest. Sometimes might pick a different arch if chasing a particular > arch problem. > > With regards, > Daniel > -- > |: https://berrange.com -o- > https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- > https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- > https://www.instagram.com/dberrange :| > _______________________________________________ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue >
_______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
