Commit Graph

35 Commits

Author SHA1 Message Date
Colin Walters
14f75f94ef ci: Split clang into separate script, run it in CoreOS CI
Let's do a build with clang as a cleanly separate context
instead of serially; and also do it unconditionally.  This
is prep for turning on more `-Werror` flow in both cases,
and also using clang `scan-build` in CI.
2021-02-01 04:54:52 -05:00
Colin Walters
86ce9ea1f5 ci: Make msrv test do full build + unit tests
I think we did this at some point, but then stopped.
Prep for https://github.com/coreos/rpm-ostree/pull/2413
because we'll need a full build of the C++ side too in order
to `cargo test`.
2021-01-26 10:31:57 +01:00
Jonathan Lebon
91b48be098 ci: Set RPM_BUILD_NCPUS when building RPMs
Otherwise, it defaults to `_SC_NPROCESSORS_ONLN` (via `%make_build` ->
`%_smp_mflags` -> `%_smp_build_ncpus` -> `%{getncpus}` ->
48c0f28834/rpmio/macro.c (L583)).
And that's going to be wrong in Kubernetes because we're constrained via
cgroups.

The `%_smp_build_ncpus` macro allows overriding this logic via
`RPM_BUILD_NCPUS`.

See: https://github.com/coreos/coreos-ci/issues/23
See: https://github.com/coreos/coreos-assembler/pull/632
See: https://github.com/coreos/coreos-assembler/pull/1287
2021-01-21 11:57:13 -05:00
Colin Walters
85f4ce448f ci: Don't run autotools twice
I started writing a comment about why we run autotools twice,
then decided that was *much* uglier than extracting the binding
rules to a separate `Makefile`.  But I forgot to go back
and remove the first part, so do that now and fix up the comment.
2021-01-04 15:36:22 -05:00
Colin Walters
08c414f897 Rework bindgen/cxx.rs usage and CI build
cxx.rs (aka cxxbridge) and cbindgen are
both generating source code.  Since the last release
we've introduced the former, and we need to ensure
that the generated cxx.rs source ends up in release tarballs
the same way as the cbindgen code.

Rationalize and clean up the binding infrastructure.
Drop support for the vendored cbindgen which we
weren't actually using:
Closes: https://github.com/coreos/rpm-ostree/issues/2392

Move the cxx-rs and cbindgen bits into the same place,
and update our CoreOS CI build to use a separate `Makefile.bindings`
that just generates the code, so our CI still "works like"
a main Koji RPM build.
2021-01-04 13:17:35 +01:00
Colin Walters
9f19ed2ac8 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-23 17:45:29 +01:00
Colin Walters
b3b4dd3d22 msrv: Bump to Rust 1.48.0
We need this for https://cxx.rs

While we're here:

 - Add some more comments/links
 - Since the Rust bits are now at the toplevel, we can explicitly
   invoke `cargo`
 - And since we can do that, use the `+` syntax to specify the
   toolchain explicitly
2020-12-15 16:17:44 +00:00
Colin Walters
f1488e52f0 Move the main Rust infra (i.e. Cargo.toml) to the toplevel
I think we should have done this as soon as it was clear that
Rust was sticking and not just an optional thing.

Reasons to make this change now:
 - More clear that Rust is going to be the majority of code in the future
 - `cargo build` and `cargo test` in a fresh git clone Just Work
 - Paves the way for using `cargo` to build C/C++ instead of Automake
2020-12-09 17:42:35 -05:00
Luca BRUNO
1c954a01cb Revert "ci: Freeze FCOS commit to f32"
This reverts commit eaf8ab8cf3.
2020-12-07 07:58:18 -05:00
Jonathan Lebon
eaf8ab8cf3 ci: Freeze FCOS commit to f32
Short-term workaround until cosa is bumped to f33. See:
- https://github.com/coreos/rpm-ostree/pull/2320
- https://github.com/coreos/coreos-assembler/issues/1863
2020-11-13 23:03:23 +01:00
Jonathan Lebon
b91e6bc9a3 ci: Run C unit tests too
We lost this during the transition from PAPR to CoreOS CI. We don't have
a lot of new tests there since new unit tests tend to be in Rust, though
we should still run what we do have.

Repurpose the `rust` branch to more generically run all unit tests
and not just the Rust ones. It still also checks that compilation
against the MSRV works fine.
2020-10-01 06:08:37 -04:00
Colin Walters
ce2f692bea ci: Use ostree from lockfile
In the scenario where ostree is in the fcos overrides but *not*
bodhi, *and* a new test requires it, our CI will fail.

We aren't hard requiring the latest ostree right now.
2020-09-08 12:56:58 -04:00
Jonathan Lebon
fdfad9561d ci: bump compose tests timeout to 60 minutes
We usually finish much faster than that, but when dependabot spams the
cluster it can be slower.
2020-08-24 10:29:15 -04:00
Jonathan Lebon
fda0be62ce ci: Constrain parallel build jobs
The default `_NPROCESSORS_ONLN` heuristic we have isn't cgroups aware.
So it thinks it has e.g. 40 CPUs when running in a k8s pod. This can
then blow through our allocated resource limits.

Declare some modest amount of RAM and CPU resources and override `make`
parallelism.

This matches what ostree does in
https://github.com/ostreedev/ostree/pull/2151.
2020-07-16 15:46:06 -04:00
Jonathan Lebon
89d79f3505 ci: request 2G of RAM for compilation
I think the `fork` errors CI is hitting might be due to more stringent
memory limit enforcements in OCP4. Let's be more explicit and actually
request 2G of RAM. We can adjust from there.

(One related thing is CPU requests; it's possible we might need to also
make that explicit and in turn adjust the `_smp_mflags` RPM macro, since
the default is unlikely to be k8s/cgroups-aware.)
2020-07-16 15:46:06 -04:00
Jonathan Lebon
8e632156f7 ci: Adapt to workspace being HOME
The CoreOS CI shared lib sets `HOME` to the workspace:

a81bfab789

and there's no easy way for it to detect when `HOME` is correctly set:

8574f04d96
853d5fdef3

For now, just work around this until we have a cleaner solution. (Though
it makes sense overall to uses `$HOME` anyway instead of hardcoding
`/root`).
2020-06-17 15:05:53 -04:00
Colin Walters
75ae584e6d tests/kola: Move into tests/kolainst, run installed
Switch to the "installed" model introduced by:
https://github.com/coreos/coreos-assembler/pull/1441

It's hard to support running tests *both* from the srcdir
and installed; in this case because we have a symlink that needs
to be followed, which kola knows how to do from the srcdir
but not when installed.  Let's establish a new convention of
`tests/kolainst`.   In our case we follow the symlink manually
for now.

That bit will be cleaned up when we eventually switch entirely
to kola tests.
2020-05-26 15:34:00 -04:00
Jonathan Lebon
53cb441597 ci: Download the latest ostree even if from stable repos
Right now, rebuilding ostree into the continuous tag is manual, so we've
only been doing it when necessary to fast-track something e.g. for
rpm-ostree or cosa (see [1] for the long-term goal).

Which means when finding an ostree to use to override in our CI-built
FCOS, we should just let dnf find whatever the latest version is, even
if it's just from the regular Fedora repos.

[1] https://github.com/packit-service/packit/issues/264
2020-05-07 21:32:35 +02:00
Colin Walters
c94639f546 ci: Explicitly fetch before build
See https://github.com/coreos/coreos-assembler/pull/1379
2020-04-21 14:02:16 -04:00
Colin Walters
0d57ab9117 ci: Actually run kola tests
Noticed in https://github.com/coreos/rpm-ostree/pull/2052#issuecomment-613694719
2020-04-18 13:52:34 -04:00
Colin Walters
8a172a2e05 rust: rustfmt(*) and (re)add a CI check for it
We haven't been consistent about doing this; I personally
think rustfmt is a big aggressive with the line wrapping
but eh, consistency is more important.

And heh so I tried to `git push --set-upstream cgwalters` and
that failed because there was an already extant `rustfmt`
branch from a while ago...looking at that code it got lost
in the CI refactoring - we're not running `build-check.sh`
at the moment.

Move the rustfmt bits into `codestyle.sh` which is closer
to where it should be anyways.
2020-04-08 02:52:30 +02:00
Colin Walters
9269c9a802 build-sys: Hard require libostree 2020.1
The current `rpm-ostree-2020.1-1.fc31.x86_64` in Fedora
was [built with a truly ancient libostree](https://kojipkgs.fedoraproject.org//packages/rpm-ostree/2020.1/1.fc31/data/logs/x86_64/root.log)
because Fedora's build system is weird and only adds packages
released after "gold" into the buildroot via an override
that times out.

This actively breaks things because rpm-ostree isn't
detecting the read-only sysroot.

Let's bump our hard requirement.
2020-03-13 23:13:44 +01:00
Jonathan Lebon
ca40b1f747 ci: migrate to new coreos-ci project
Mostly minor tweaks to adapt to the new custom steps. We have a pretty
involved pipeline here so we don't actually use the higher-level steps
like `fcosBuild`.
2020-03-03 14:55:30 +01:00
Jonathan Lebon
4b15c59b77 ci: Move cargo test into ci/msrv.sh
We need `cargo` in our `PATH` and we already do the `PATH=...` dance in
`ci/msrv.sh`. This only worked before because we were inadvertedly
re-installing cargo when calling `ci/build.sh`, which was fixed in the
previous commit.
2020-02-25 16:48:15 +01:00
Jonathan Lebon
7ad4d58bbc ci: Bump compose tests timeout to 45m
Still trying to find the sweet spot on this. I think it may also depend
on how fast/busy the node we get allocated to is.
2020-01-28 11:13:47 -08:00
Jonathan Lebon
654ab64409 ci: Re-org stages and parallelize tests
Build FCOS and run vmcheck in the same container, since it's only used
for that anyway right now. The main advantage is that we save time
provisioning another container and not having to stash and unstash the
FCOS image.

Also, since the compose tests don't actually need to wait for the FCOS
image, start running them in parallel with the FCOS + vmcheck branch.
2020-01-08 16:42:54 +01:00
Jonathan Lebon
9daea46d66 tests/compose: Target FCOS 31, move off of PAPR
Again, a lot going on here, but essentially, we adapt the compose tests
to run either privileged or fully unprivileged via supermin, just like
cosa.

I actually got more than halfway through this initially using `cosa
build` directly for testing. But in the end, we simply need more
flexibility than that. We want to be able to manipulate exactly how
rpm-ostree is called, and cosa is very opinionated about this (and may
also change from under us in the future).

(Another big difference for example is that cosa doesn't care about
non-unified mode, whereas we *need* to have coverage for this until we
fully kill it.)

Really, the most important bit we want from there is the
unprivileged-via-supermin bits. So we copy and adapt that here. One
obvious improvement then is sharing this code more easily (e.g. a
`cosa runasroot` or something?)

However, we still use the FCOS manifest (frozen at a specific tag). It's
a realistic example, and because of the lockfiles and pool, we get good
reproducibility.
2020-01-08 16:42:54 +01:00
Jonathan Lebon
c59b9de3d4 ci: Run Rust unit tests
We definitely want this too.
2019-12-20 21:16:24 +01:00
Jonathan Lebon
c7a9c3b1dd Rework vmcheck to use kola spawn, move off of PAPR
There's a lot going on here, but essentially:

1. We change the `vmcheck` model so that it always operates on an
   immutable base image. It takes that image and dynamically launches a
   separate VM for each test using `kola spawn`. This means we can drop
   a lot of hacks around re-using the same VMs.
2. Following from 1., `vmoverlay` now takes as input a base image,
   overlays the built rpm-ostree bits, then creates a new base image. Of
   course, we don't have to do this in CI, because we build FCOS with
   the freshly built RPMs (so it uses `SKIP_VMOVERLAY=1`). `vmoverlay`
   then will be more for the developer case where one doesn't want to
   iterate via `cosa build` to test rpm-ostree changes. I say "will"
   because the functionality doesn't exist yet; I'd like to enhance
   `cosa dev-overlay` to do this. (Note `vmsync` should still works just
   as before too.)
3. `vmcheck` can be run without building the tree first, as
   `tests/vmcheck.sh`. The `make vmcheck` target still exists though for
   finger compatibility and better meshing with `vmoverlay` in the
   developer case.

What's really nice about using kola spawn is that it takes care of a lot
of things for us, such as the qemu command, journal and console
gathering, and SSH.

Similarly to the compose testsuites, we're using parallel here to run
multiple vmcheck tests at once. (On developer laptops, we cap
parallelism at `$(nproc) - 1`).
2019-12-13 19:18:30 +01:00
Jonathan Lebon
9d73458f0c ci: Add the built RPMs as cosa overrides
So that the built FCOS has them. This is a prereq for actually testing
what we built in `vmcheck`.
2019-12-13 19:18:30 +01:00
Jonathan Lebon
07dfb8dc3e ci: Archive built RPMs
That way, anyone can easily download the latest built RPMs from master
or a specific PR. This isn't a replacement for automated builds in Koji
though since it's not multi-arch.

Also fetch the tags so that the NEVRA derived from `git describe` is
nicer.
2019-12-13 19:18:30 +01:00
Jonathan Lebon
f673305920 ci: re-use variable for container images
Makes it less repetitive and allows controlling the images from a
central place.
2019-12-13 19:18:30 +01:00
Jonathan Lebon
289af613a9 ci/jenkins: don't pass GIT_COMMIT to ci-commitmessage-submodules.sh
Jenkins is tricky: it does an initial checkout, merges the PR head into
the target branch, then creates the pod. Once in the pod, we do a
`checkout scm` which *also* merges the PR head into the target branch.
However, the `change.GIT_COMMIT` variable we get from that is set to the
SHA of the first merge, not the second one. Which... yeah is super
confusing since we explicitly assign `change` from that `checkout scm`
operation. So that's probably a valid bug.

This was then throwing off `ci-commitmessage-submodules.sh` since it
didn't find the merge commit in the graph.

Anyway, not going to spend more time on this. Let's just not pass any
commit at all. The git range `origin/master..HEAD` already does what we
want (go through all the commits in HEAD *not* in master).
2019-10-03 13:39:11 -07:00
Jonathan Lebon
677c3c8b29 ci: Also bump MSRV to 1.37.0 for CCI Jenkins
Just split it out into a separate script for easier sharing.
2019-10-01 11:26:29 -04:00
Jonathan Lebon
46ab7d1ae8 ci: Add Jenkins pipeline
This is an experiment in using Jenkins pipelines for our CI. See similar
initiatives in coreos-assembler[1] and fedora-coreos-config[2].

For now, this only does the following testing:
- checks commit for unintended submodule bumps
- checks the minimum Rust version
- builds RPMs
- builds FCOS (with the new RPMs both for executing the build
  itself, as well as included in the built OS)

There are dummy placeholders for where we'd actually run the vmcheck
and the compose testsuites. Let's address those trickier parts as
follow-ups.

[1] https://github.com/coreos/coreos-assembler/pull/667
[2] https://github.com/coreos/fedora-coreos-config/pull/131

Closes: #1899
Approved by: cgwalters
2019-09-18 15:15:28 +00:00