build: Add conditional builds for rpm build customization and related build script refactoring #541
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sjd78
requested review from
ahadas,
bennyz,
didib,
emesika,
ljelinkova,
michalskrivanek,
mwperina,
oliel,
sandrobonazzola and
sgratch
as code owners
sjd78
force-pushed
the
refactor_spec_with
branch
3 times, most recently
from
86ce3f2 to
3c02510
Compare
sjd78
changed the title
- Removed the file `milestone-config.sh`. It is not used anywhere
in the codebase.
- Remove the .in template and associated references
Instead of sed swapping in a 0 or 1 for a `%define` variable
in the `spec.in` file, or running rpmbuild with a `--define`,
use conditional builds. See [1] for how they work.
With a conditional build, source rpms retain the ability to build with
different options depending on how `rpmbuild` is called. This allows
a minimal (en_US, Firefox, Safari) or full (all locales, all browsers)
build from srpm to be selected at build time using `--with` or `--without`
build options.
Since at least copr builds chroots directly from a srpm, conditional
builds can be used to change build options. With this change, a
"full build" can be forced simply by configuring the target chroot
setting "without" to include "ovirt_build_full".
Notes:
- A `ovirt_build_full` is the is the default
- For GitHub CI, a minimal build with unit tests is used
- For copr builds, use `build-srpm.sh -c` to keep CI and copr
srpm builds in the same place
- Refactored `build-srpm.sh` and `build-rpm.sh`:
- each script has only the envvars setup that the work needs to run
- use `getopts` to parse options so they don't positionally clash
- add a snapshot build release suffix if the Makefile var `MILESTONE`
is not empty
[1] - https://rpm-software-management.github.io/rpm/manual/conditionalbuilds.html
sjd78
force-pushed
the
refactor_spec_with
branch
from
3c02510 to
ed44ebd
Compare
sandrobonazzola
requested review from
BrooklynDewolf and
dupondje
and removed request for
ljelinkova and
oliel
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
When working with a community member on the new Georgian translations, I created a custom copr repo to distribute translation updates as rpms. This allowed the translator to use my copr repo and just
dnf upgradeto test his translations. The problem was that I could not enable a full build on a snapshot releases. Instead of just pointing my copr repo to my branch with updated translation files, I also needed to patch the spec file.With the conditional builds, I can enable a full build (with not unit tests) on my copr repo and point the build directly to my translation update PR.
Summary
Instead of sed swapping in a 0 or 1 for a
%definevariable in thespec.infile, or running rpmbuild with a--define, use conditional builds. See rpm conditional build docs for how they work.With a conditional build, source rpms retain the ability to build with different options depending on how
rpmbuildis called. This allows a minimal (en_US, Firefox, Safari) or full (all locales, all browsers) build from srpm to be selected at build time using--withor--withoutbuild options.Since at least copr builds chroots directly from a srpm, conditional builds can be used to change build options. With this change, a "full build" can be forced simply by configuring the target chroot setting "without" to include "ovirt_build_full".
Details
A
ovirt_build_fullis the is the defaultRefactored
build-srpm.shandbuild-rpm.sh:getoptsto parse options so they don't positionally clashMILESTONEis not emptyFor GitHub CI, a minimal build with unit tests is used ("SNAPSHOT" in the pom.xml version string triggers a
MILESTONE=masterand that causesovirt_build_minimalto be the default option)For copr builds, use
build-srpm.sh -cto keep CI and copr srpm builds in the same placebump_release.shno longer needs to patch.copr/Makefilesince thebuild-srpm.shscript can detect snapshot vs release builds by looking at theMILESTONEMakefile varRemoved the file
milestone-config.shsince it is not used anywhere in the codebaseExample
My translation testing copr repo: https://copr.fedorainfracloud.org/coprs/sdickers/enUS_kaGE/
ovirt-engine package referencing my PR branch:
Settings for the centos8-stream chroot:
