Re: Use cases for 'fedpkg scratch-build'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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é <berrange@xxxxxxxxxx> 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@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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux