rpm-ostree/ci/build.sh

#!/usr/bin/bash
# Install build dependencies and then build.

set -xeuo pipefail

dn=$(dirname $0)
. ${dn}/libbuild.sh

${dn}/install-extra-builddeps.sh
export PATH="$HOME/.cargo/bin:$PATH"
${dn}/installdeps.sh
# make it clear what rustc version we're compiling with (this is grepped in CI)
rustc --version

export LSAN_OPTIONS=verbosity=1:log_threads=1
# And now the build
build --enable-installed-tests --enable-gtk-doc ${CONFIGOPTS:-}
ci: Delete dockerfile, move to common scripts, consolidate gcc/clang The Dockerfile is problematic since we can't update it atomically. I also really dislike reliance on the Hub. Further, I think rather than caching our build deps as built containers, we should be caching RPMs in CI. And we should be using rpm-ostree at some point to assemble filesystem trees faster. Also, consolidate the clang to be serial with gcc, since while we lose a tiny bit of parallelism, it's not really worth its own context right now. Closes: #759 Approved by: jlebon 2017-04-28 19:29:25 +03:00			`#!/usr/bin/bash`
ci: Split out script to install deps This should also make it useful for bootstrapping a test container locally. Closes: #1606 Approved by: cgwalters 2018-10-11 23:14:43 +03:00			`# Install build dependencies and then build.`
ci: Delete dockerfile, move to common scripts, consolidate gcc/clang The Dockerfile is problematic since we can't update it atomically. I also really dislike reliance on the Hub. Further, I think rather than caching our build deps as built containers, we should be caching RPMs in CI. And we should be using rpm-ostree at some point to assemble filesystem trees faster. Also, consolidate the clang to be serial with gcc, since while we lose a tiny bit of parallelism, it's not really worth its own context right now. Closes: #759 Approved by: jlebon 2017-04-28 19:29:25 +03:00
			`set -xeuo pipefail`

			`dn=$(dirname $0)`
			`. ${dn}/libbuild.sh`

ci: Introduce install-extra-builddeps.sh We need to cleanly split off "test dependencies" that we install inside the cosa pod from builds (where we won't have `cargo`) from the build time where we use the cosa buildroot image. Prep for using https://cxx.rs 2020-12-11 23:39:04 +03:00			`${dn}/install-extra-builddeps.sh`
Also export PATH here Prow job is running this one directly. We really need to clean this up... 2021-02-03 15:48:20 +03:00			`export PATH="$HOME/.cargo/bin:$PATH"`
ci: Split out script to install deps This should also make it useful for bootstrapping a test container locally. Closes: #1606 Approved by: cgwalters 2018-10-11 23:14:43 +03:00			`${dn}/installdeps.sh`
ci: Build the whole tree, not just rust bits Otherwise, we're not testing everything. E.g. the cbindgen bits. Closes: #1778 Approved by: cgwalters 2019-03-07 23:42:41 +03:00			`# make it clear what rustc version we're compiling with (this is grepped in CI)`
			`rustc --version`

ci: Sync with ostree We have some drift; keep this more in sync so we maintain the rpm/yum hackarounds for example in one place. I backed out the ASAN bits though pending at least a newer gpgme: <https://github.com/projectatomic/rpm-ostree/pull/1000#issuecomment-331278758> Closes: #1000 Approved by: jlebon 2017-09-19 17:40:35 +03:00			`export LSAN_OPTIONS=verbosity=1:log_threads=1`
jigdo: V4: Use archful provides for jigdoRPM Requires When I tried to use my WIP client patches to do: `rpm-ostree rebase rojig://fahc:fedora-atomic-host`, I got a missing file object which turned out to be the client importing the i686 RPMs. This was passing in the test suite because we don't mirror i686 of course, but on the client side right now we end up using all enabled repos, and since Fedora is multiarch, the behavior is going to be...not predictable. Thinking a bit about on this problem I actually happened to recall the RPM `%{_isa}` macro which is used in Fedora in various places; for example to "arch bind" `-devel` packages to their base. See for example [this case](https://src.fedoraproject.org/rpms/ostree/blob/33c7dc02bc4f14a6acd7679cc4d84e9629294ae4/f/ostree.spec#_79) in libostree. As I noted at first, the core problem here is that the "final" RPM architecture field is not symmetric in any way with the definition of that `%{_isa}` macro. See: https://github.com/rpm-software-management/rpm/blob/d9d47e01146a5d4411691a71916b1030ac7da193/installplatform#L25 The third solution I ended up on here is to iterate over the `Provides` on the server side and we take the first thing that matches `Provides: %{name}(whatever)`. I briefly thought about trying to somehow drive into libsolv the logic to prefer the jigdoRPM's native architecture...IIRC yum did something like that in the past but it was never done in libsolv? Anyways the dependencies here are now more correct, so other tools will also handle it. Closes: #1213 Approved by: jlebon 2018-01-18 00:25:39 +03:00			`# And now the build`
			`build --enable-installed-tests --enable-gtk-doc ${CONFIGOPTS:-}`