| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
It was added for the collections bits, but we made that stable.
It's now just cruft and we're very unlikely to reuse the infrastructure
again.
Motivated by a unit test failure when running from a tarball:
https://github.com/ostreedev/ostree/issues/2313
|
|
|
|
| |
See latest in https://github.com/coreos/fedora-coreos-tracker/blob/master/docs/ci-and-builds.md
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was my first experiment with using Rust in this way; I gained
a lot of knowledge from it. But, we don't really gain
anything from the code as it is today - while it is "bit fiddling"
code, the C code is well tested.
We have a lot of compile-time options, and trimming them will be
helpful.
We've also gotten pushback on hard requiring Rust client side.
Instead, what I'd like to do is hopefully soon create an `ostree-system`
crate that uses the existing `ostree` library and can contain
code drained from the rpm-ostree Rust and used by other projects perhaps.
So the goal here is really more Rust, but we need to focus our
efforts on where it's most valuable.
|
|
|
|
| |
Merged in https://github.com/coreos/fedora-coreos-config/pull/586
|
|
|
|
|
|
|
|
|
|
| |
That test will not make it into the fedora-coreos-config repo until the
libostree fix gets percolated down. PR is:
https://github.com/coreos/fedora-coreos-config/pull/586
But we want to make sure that the fix does work and that we don't
regress on it. So manually fetch it for now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds infrastructure to the Rust test suite for destructive
tests, and adds a new `transactionality` test which runs
rpm-ostree in a loop (along with `ostree-finalize-staged`) and
repeatedly uses either `kill -9`, `reboot` and `reboot -ff`.
The main goal here is to flush out any "logic errors".
So far I've validated that this passes a lot of cycles
using
```
$ kola run --qemu-image=fastbuild-fedora-coreos-ostree-qemu.qcow2 ext.ostree.destructive-rs.transactionality --debug --multiply 8 --parallel 4
```
a number of times.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Regression from
https://github.com/ostreedev/ostree/pull/2158/commits/5d7f897908dbf7f471ddfdbd6c29a84ac6bc0bda
I'm not sure how (or if) this passed before, the job logs have
been GC'd.
This is a bit confusing but basically right now ostree/rpm-ostree's
CI jobs don't use `/srv/fcos` - it might make sense to port
these to `fcosBuild` but that needs investigation.
|
|
|
|
|
| |
Make sure we don't break the FCOS live image. PXE is probably sufficient,
but also test the ISO image for good measure.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 rpm-ostree now does in
https://github.com/coreos/rpm-ostree/pull/2155.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a lot going on here. First, this is intended to run
nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252).
With Rust we can get one big static binary that we can upload,
and include a webserver as part of the binary. This way we don't
need to do the hack of running a container with Python or whatever.
Now, what's even better about Rust for this is that it has macros,
and specifically we are using [commandspec](https://github.com/tcr/commandspec/)
which allows us to "inline" shell script. I think the macros
could be even better, but this shows how we can intermix
pure Rust code along with using shell safely enough.
We're using my fork of commandspec because the upstream hasn't
merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+).
This model is intended to replace *both* some of our
`make check` tests as well.
Oh, and this takes the obvious step of using the Rust OSTree bindings
as part of our tests. Currently the "commandspec tests" and "API tests"
are separate, but nothing stops us from intermixing them if we wanted.
I haven't yet tried to write destructive tests with this but
I think it will go well.
|
|
|
|
|
|
| |
Follow the precedent set in https://github.com/coreos/rpm-ostree/pull/2106
and rename the directory, to more clearly move away from the
"uninstalled" test model. Prep for Rust-based tests.
|
|
|
|
|
|
|
|
|
|
|
| |
This builds on
https://github.com/coreos/coreos-assembler/pull/1441
to install our tests rather than running them from the source
directory. This model will more cleanly allow us to ship
our tests along with a test container or elsewhere, separate
from the source directory.
Also prep for https://github.com/ostreedev/ostree/pull/2048
|
|
|
|
|
|
|
|
|
| |
All of the underlying libostree APIs have supported passing `NULL`
for a merge deployment for...a long time. But we never plumbed
it up into the CLI.
Add a `--no-merge` option to aid people who want to do a "factory reset":
https://github.com/ostreedev/ostree/issues/1793
|
|
|
|
|
|
| |
The goal is to test "no options" build - and eventually tests.
(We're not actually including libsodium in the cosa buildroot right
now, but we may in the future)
|
|
|
|
|
|
| |
This was changed recently and broke us since we do explicitly call
`fcosKola` instead of implicitly via `fcosBuild`. Adapt to the new
semantics.
|
|
|
|
|
|
|
|
|
| |
We were using `--no-test-exit-error` for upgrade tests but weren't
actually checking for test failures after.
Instead of running kola directly, just use the `fcosKola` custom step
which automatically takes care of e.g. running tests in parallel and
archiving results.
|
|
|
|
| |
This one is very relevant for ostree.
|
|
|
|
|
| |
Use the new custom steps. I think we could simplify things further by
using `fcosBuild` but let's start with this for now.
|
|
|
|
|
|
|
|
|
|
|
| |
Move the alternative builds into the Jenkinsfile.
Update it to do a FCOS build + kola run.
We drop the flatpak/rpm-ostree runs for now; the former
will needs some work to do the automatic virt bits. The
latter I think we can circle back to when we e.g. figure
out how to include rpm-ostree's tests in kola runs.
|
|
See https://github.com/jlebon/coreos-ci
This is just a start to test, cut down from the rpm-ostree version.
|