IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The compose tests are expensive; each run involves running
all the `%post` scripts and `dracut` etc. This is definitely
a source of timeouts in CCI.
Remove `test-boot-location-modules.sh` - it's the default
now and is used by FCOS. Add dedicated script where we can
test all these things by default after a `cosa build`.
This aims to move the compose tests to only cover bits *not*
in cosa like the non-unified-core path.
This is a major downside of reworking and generating new CI
flows, it's super easy to lose testing what you intend to.
Also, we clearly need to figure out a flow where this is shared
across repos, since I don't want to copy-paste this into e.g. ostree too.
That's https://github.com/coreos/fedora-coreos-tracker/issues/263
We have fully transitioned to cxx-rs! This drops a lot of now
dead code; only one binding system to think about generating
source code. For example, a notable advantage of cxx-rs
is it doesn't scan the whole source code, so running `make`
doesn't spew errors from cbindgen not understanding bits.
It turns out we accidentally added GPL'd code into the Rust
side, which wasn't intentional on my part and I think it's since
been copied around.
Honestly I think half of the problem is the gigantic
"blah blah blah GNU General blah blah" just makes people's eyes
glaze over. In contrast the `SPDX-License-Identifier` is short
and obvious.
So let's validate that in CI.
This follows a similar change in ostree:
https://github.com/ostreedev/ostree/pull/1439
If we merge this I'll do the C/C++ side too after that.
Our "CoreOS CI Jenkins" flow is great, but the reliability/debuggabilty
of the system isn't the best. This is an experient to *add* another CI
flow that can be run in Prow too.
I'd like to at least have a basic e2e (compose tree, run client tests)
flow that can operate in Prow so that if CoreOS CI Jenkins is down or
flaky, we at least have some confidence in our commits.
Longer term I think we can figure out how to better share CI flows
across these:
https://github.com/coreos/fedora-coreos-tracker/issues/263#issuecomment-772903759
Now that `ci/installdeps.sh` gracefully exits if run as non-root,
we can fold the cargo bits into the our build scripts and avoid
invoking both of them.
However, now we need to split test deps to separate file because
we won't have `cargo` in the main cosa pod. This also fixes a FIXME.
Steal the `grep` invocation from cosa and make it a declarative
text file so we can have comments per package etc.
Doing the distro-sync costs ~3 minutes per execution, and it
happens multiple times. Let's just ensure our images are up
to date instead.
Also drop the continuous repo (for now) - we added this
to test bleeding edge ostree, but I think we need to reintroduce
"git master" builds as whole separate CI flow (layered container)
instead.
So...at some point we somehow lost `-Wall` in our
default compiler flags which means we were missing some
potentially important warnings. And
we used to have `-Werror` on in CI which combined
with the above was strongly opinionated about not
landing warnings in git master.
Our default stance here remains the same; we have
an opinionated set of `-Werror=` that applies in
*all* configurations. However that set moves
into Automake - I don't think we need to do
compiler version detection anymore, we can assume
a modern compiler.
We also add back in `-Wall` by default now.
Further in CI, add `-Werror`. The implementation
here is in our buildsystem rather than
`export CXXFLAGS=-Werror` because unfortunately
we have to fix things in libdnf too, and I don't
want to block entirely on that.
Since we need to set HOME and PATH, let's do that in a central
place rather than scattering it around by having all of
our entrypoint scripts source the `libbuild.sh` shell "library".
Move the CoreOS CI entrypoint into a script like the others.
Actually it seems OpenShift sets HOME=/ for some reason; probably
related to the non-root uid default.
And whole lot of the Prow jobs do `export HOME=$(mktemp -d)` today.
I am tempted to add a `cosa entrypoint` command or something
that sanitizes the environment setup.
The way this tries to replace the system Rust is hacky and
actually I realized belatedly I may have broken it recently; basically
`installdeps.sh` re-adds the system one, and it's hard to be sure
with our current buildsystem we're using the newer one from `$PATH`.
What we really want to do here is use a CentOS8 buildroot,
which will automatically enforce this in a better way along
with solving other problems. But right now we've broken
that because libdnf requires a too-new libmodulemd.
So let's just rely on the Fedora rust for now.
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.
Nothing is using this; our unit tests don't change uids and
most of our testing is in VMs.
Dropping this makes it easier to run the scripts outside of CI.
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`.
This fixes `install-extra-builddeps.sh` helper, by letting cargo
detect whether the target binary is already present in the
environment with the expected version.
This is in order to avoid mismatches in generated code when the
library version is bumped, and stale binaries are present on
the system.
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.
AFAICT, we just need `cxxbridge` to be in the `PATH` of the building
user. Let's avoid targeting privileged paths so devs can just run this
script directly without `sudo`.
This is much better than bindgen because it's fully safe. It's
much more ergonomic too:
- Invoke Rust methods-on-structs just like C++ methods-on-structs
- Rust `Result<>` is translated automatically to exceptions
See https://cxx.rs/context.html for more.
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
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
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.
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.
This is needed by the compose tests. This is part of cosa already, which
is why CI isn't hitting this, but we want to support users not
developing on top of the cosa buildroot container that can just run
`ci/installdeps.sh`.
Jenkins does its own `git merge` when testing PRs. Doing a naive
`git diff ${merge_commit}^..${merge_commit}` won't work right because
it might perform a diff across multiple commits.
What we want to do here is to just skip trivial merge commits or
otherwise error out on them if they're non-trivial (since it likely
means that one did conflict resolution manually instead of rebasing,
which we should encourage).
The `origin/master..$HEAD` range will correctly still contain all the
parents of any merge commit which is not yet in `origin/master`.
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.
FAHC is super out of date now. The way to have access to newer packages
is via the continuous tag, which is still manual for now, but at least
targets the right Fedora release.
Doing builddep once based on the baked config and then once more from
the spec file can cause issues sometimes. For example, right now the
latest rpm-ostree release uses libmodulemd1, but we want to rebase to
libmodulemd (2.0). And `dnf` will get confused trying to move from one
to the other.
Really, we don't need to builddep from the last release at all, so just
drop that and rely only on the spec file.
Adapt `pkg_install_builddeps` to allow no args to mean only installing
the basic buildroot stuff like `dnf builddep` and `@buildsys-build`.
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.
We've already manually installed dependencies higher up. This saves us
some time, but also we don't want the script to e.g. re-install cargo.
(This also works as a short term hack we need to adapt to libdnf moving
to `libmodulemd-2.0` due to `ci/installdeps.sh` not being entirely
idempotent).
