We successfully switched to F28 in rpm-ostree. Time to follow suit here.
We exclude flatpak for now since we're still hitting test issues there
on F28.
Closes: #1601
Approved by: cgwalters
I'd like to start working towards migrating the OSTree CI towards the
new PAPR model running in PACI. In order to take it for a test drive
(pun intended) without yet replacing our current CI, the new PAPR now
knows to look for a `.papr-ex.yaml` file. So as to not conflict with the
current PAPR, no GitHub statuses will be output other than a
`required-ex` label, which plays the same role as `required`. For more
information, see:
https://github.com/projectatomic/papr/commit/85b1d0a91eba6597d01b52b674de38a876f030fe
The `.papr-ex.yaml` version is essentially the same except for:
1. the `FAH27-insttests` suite runs directly in the scheduled container
(notice the new `kvm: true` key)
2. the `host:` based contexts (rpm-ostree and flatpak) are missing since
we don't support provisioning a host just yet
Keeping them in sync could get annoying, though building confidence in
the new approach will allow us to migrate faster.
Closes: #1587
Approved by: cgwalters
Let's get practical faster in the manual and have a simple "Hello World"
example right off the bat to hopefully make it easier to grok how OSTree
works.
Also some minor tweaks on wording around comparisons to git.
Closes: #1581
Approved by: cgwalters
Let's add a semi-colon between the "bootconfig swap" part and the
"deployment count change" to make it more clear they're separate
statements.
Closes: #1575
Approved by: cgwalters
This new information is already mostly part of `ostree.repo(5)`, though
let's put it in `ostree(1)` as well since that's where the switch is
officially documented.
Closes: #1560
Approved by: cgwalters
When comparing deployments to determine whether we need a new
bootversion, we should also check whether the commit "version" metadata
is the same. Otherwise, we may end up with the a bootconfig whose
`title` includes a version that doesn't match the one from the
deployment checksum.
Closes: https://github.com/projectatomic/rpm-ostree/issues/1343Closes: #1556
Approved by: cgwalters
This is not used by any test, nor is it packaged. Though let's just port
it over to py3 to certify our codebase completely py2-free. I've
manually checked that the script is still functional.
Closes: #1546
Approved by: cgwalters
In a world progressively unapproving of python2, let's be a bit smarter
and support testing on platforms that only have python3 installed.
Closes: #1546
Approved by: cgwalters
I'm trying to get ostree tests to pass in OpenShift as part of our CI
move but I've been seeing lots of failures related to GPG tests. It
finally turned out to be because libgcrypt doesn't behave well on older
kernels that don't have `getrandom()` (the cluster is running on RHEL7).
Thankfully, there's a new build with a fix for this. Pull that in
manually until it gets into stable.
For more information, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1542453Closes: #1547
Approved by: cgwalters
Follow up to #1536; we are now running all the testsuites on merges, but
we weren't actually blocking on their success!
Closes: #1552
Approved by: cgwalters
It seems like 240 retries is just not long enough for all the
non-destructive tests running in parallel to finish. Let's crank that up
to 500 retries.
Closes: #1548
Approved by: cgwalters
Somehow, this slipped through in #1513. We weren't inheriting anymore,
so `branches` defaulted back to just `master`. This means we weren't
gating on most of the containerized builds anymore. Ouch!
It'd make sense to teach PAPR to allow some defaults across all
testsuites, even in the `inherit: false` case. Though it's tempting to
also just change the hardcoded PAPR default to those branches since our
use of Homu + PAPR at this point is pretty ubiquitous, and it doesn't
really hurt for the ones that don't use it.
Closes: #1536
Approved by: cgwalters
We do already have `http-headers`, which potentially could be used to
allow clients to completely override the field, but it seems like the
more common use case is simply to append.
Closes: #1496
Approved by: cgwalters
Allow users to pass `<remote>:` to list all refs we have locally
belonging to `<remote>`. Also (re-)allow the similar `<remote>:.` syntax
for backwards compatibility with flatpak.
Closes: #1500
Approved by: cgwalters
Jonathan Lebon