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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
All this does is put the immutable bit on the target directory.
The intention is to replace this bit to start:
8b205bfbb9/src/create_disk.sh (L229)
However, the real goal here is to add code in this file
to handle redeploying the rootfs for Fedora CoreOS which
combines OSTree+Ignition:
https://github.com/coreos/fedora-coreos-tracker/issues/94
Basically doing this in proper Rust is going to be a lot
nicer than shell script in dracut modules. Among other
details, coreutils `mv` doesn't seem to do the right thing
for SELinux labels when policy isn't loaded.
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).
We want to run the unit tests after a build, so do that.
Furthermore, this actually installs the binaries, which
means if we do it as part of a `Dockerfile` build, we
can use that image for further testing.
This is the rpm-ostree equivalent of `dnf history`. As opposed to the
history of the refspec (i.e. `ostree log`), this shows the history of
the system, i.e. the refspecs the host deployed, checksums, versions,
layered packages, etc... The amount of details remembered is similar to
what shows up in `status`.
There's definitely some further enhancements possible (e.g. printing
package diffs, displaying rollbacks), though this seems in good enough
shape as a first cut.
Closes: #1489Closes: #1813
Approved by: cgwalters
This has a bit of history, but essentially in 1c01141e, we made both
`upgrade` and `deploy` automatically exit 77 if there were no changes.
Then in c3f1e7c8, we only changed `upgrade` so that it became gated
behind `--upgrade-unchanged-exit-77`.
I think we should carry this forward into `deploy` as well. The way I
look at this is: the default UX shouldn't require users to care about
special exit codes. That's something scripts care about. In its vanilla
form, either a command should error out or succeed.
This patch tries to add some consistency by introducing a new
`--unchanged-exit-77` in both `deploy` and `upgrade` (where it just
replaces the previous switch). The naming here matches what `install`
has too.
So... this does break backwards compatibility for any scripts which
relied on that behaviour. Though the only app I know today which wants
deploy semantics and doesn't use the D-Bus API is Zincati, which
actually hit this issue. There's also RHCOS, though the `pivot` there
uses `rebase`, not `deploy`. So overall, I think this is worth breaking
now while we're still in a transitionary period in the downstreams?
Closes: #1906
Approved by: cgwalters
We were merging some keys with list values by overriding the full list
instead of appending. Fix those.
Also add some missing keys we weren't merging at all.
Closes: #1908
Approved by: cgwalters
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/131Closes: #1899
Approved by: cgwalters
Since D-Bus 1.9.18 configuration files installed by third-party should
go in share/dbus-1/system.d. The old location is for sysadmin overrides.
Closes: #1903
Approved by: jlebon
`umask` is one of those really evil Unix things...it's pretty
crazy actually there's still no threadsafe way to "`mkdir` ignoring umask".
This surfaced in someone using coreos-assembler with a working
directory of mode `0750` and having that surface in the target
rootfs.
Ref: https://github.com/coreos/fedora-coreos-tracker/issues/272Closes: #1902
Approved by: jlebon
This is one of the tests right now that assumes it's running on f29.
We might be sort of in this awkward dual path for a while where we want
tests to run on both f29 (i.e. FAH) and f30 (i.e. FCOS).
Closes: #1900
Approved by: cgwalters
From Rust v1.37, `cargo vendor` is now baked. Stop building it, and
tweak the vendoring script to adapt to the new UX.
Closes: #1900
Approved by: cgwalters
So this is a somewhat significant change, but I'd like to try having the
canonical spec file upstream. A few reasons for this:
1. We integrate tightly with the distros we're destined for, and so
we're in a pretty good position for knowing how the software should
be packaged.
2. We can atomically change packaging along with the rest of the code.
This has important ramifications, including that it'll be easier to
integrate with continuous build services like Packit, but releases
will also be less fraught with last-minute packaging fixes.
3. I'm playing with Jenkins pipelines and there I'd like to make RPMs
the "artifact" that gets moved down the pipeline into later stages
(e.g. `cosa build`). We could even eventually make it an actual
external artifact so that anyone can easily download RPMs from any
random PR for testing. (And in fact, with a thin yumrepo layer on
top, it could be used to replace Packit/rdgo entirely).
Not that this approach doesn't have issues as well (e.g. on the dist-git
side, we'll need some minimal tooling to merge in the changelog), though
I think it's worth trying out.
Closes: #1900
Approved by: cgwalters
This is a bit of a hack, but does the trick now. Eventually, we'll need
to either bump rdgo to f30, or set up continuous builds some other way
(e.g. Packit or Jenkins pipelines).
Closes: #1900
Approved by: cgwalters
Jenkins' `checkout scm` gives us the exact commit that we're testing.
Allow passing that to the submodule commit message checker so it doesn't
use `HEAD` (which is likely GitHub's merge commit).
Closes: #1900
Approved by: cgwalters
The command isn't interesting right now (the YAML treefile stuff mostly obsoletes it)
and the CI context costs money/time.
Closes: #1898
Approved by: jlebon
We have contacted all contributors to the code in `rust/` and
that code is now all relicensed under the "standard Rust license"
of `Apache 2.0 OR MIT`.
[Due to an accident](https://github.com/projectatomic/rpm-ostree/issues/1890),
some GPLv2+ code was imported in the C side, and we're unlikely to
easily change that now. Make this more official by adding the GPLv2.
I'd like to go through the C code and add SPDX and possibly investigate
relicensing some of the GPLv2+ code to LGPLv2+ but, not right now.
For a bit more about Rust and SPDX, see [this issue](https://github.com/rust-lang/cargo/issues/2039).
Closes: https://github.com/projectatomic/rpm-ostree/issues/1890Closes: #1897
Approved by: jlebon
Point at FCOS and not Project Atomic. Add an inline "Why"
section since people will want to know that right away.
(An great thing about Github is the prevalence it gives to `README.md`;
projects should use that as an "elevator pitch")
Drop outdated bits in `background.md`.
Closes: #1895
Approved by: jlebon
I have multiple outstanding PRs that use it and they conflict on
this, so let's just upstream it now.
It helps avoid some use of `unsafe` talking to libc directly.
This is an exact copy of https://github.com/ostreedev/ostree/pull/1906
for now. From that commit message:
I'd like to add OpenShift's prow to this repository. Let's start
by adding a Dockerfile - it doesn't really do anything besides build.
However...I've lately been thinking about e.g. shipping the ostree tests
as an image, and then e.g. we could test FCOS by running that container
(which would orchestrate the host's ostree).
Anyways, not doing that right now but this is a start.
I was debugging a failure in cosa when running in unprivileged podman,
with this patch the error is:
`error: Importing package 'alternatives': Writing tmpfiles mtree: llistxattr: Is a directory`
And that finally made it obvious to me that the problem is not using
tmpfs for `/tmp` (well, this is a bug in fuse-overlayfs).
Anyways, let's prefix errors some more on general principle.
Closes: #1889
Approved by: rfairley
Since we have to pull it anyways to do a build, let's use it
as a buildroot. This should fix CI which broke because we were
doing a f29 build but cosa is f30, and libostree differed.
I wanted to use this in another project, and I don't think
we're the only ones. I extracted the code, added better docs
and tests, and published to crates.io:
https://crates.io/crates/openat-ext
When hoisting deploy flags from the option dict, we want the default
values to take effect *only if* the option wasn't specified in the dict.
Instead, because we initialized the return value with the default flags,
the option set couldn't override a flag which was part of the defaults
(IOW, a flag that's on by default couldn't be turned off through the
options dict).
Came upon this issue by trying to use the older `Deploy()` and
`Rebase()` D-Bus APIs which pass default values like `ALLOW_DOWNGRADE`,
but the option dict specifies `allow-downgrade=false`. (We could say,
"you should use the newer `UpdateDeployment()` API", but the cat is
mostly out of the bag at this point on options that get shoved into the
dict and take effect on both APIs).
In FCOS, we want to make sure that Zincati is always deploying a newer
tree to prevent downgrade attacks in certain threat models.
For completeness, also add the option to `rebase`.
* treefile: Rework test helper
Have each test clearly hold its tempdir; this way we can have a simple
helper function rather than a struct with an unreferenced parameter.
Also use `utils::write_file`.
Prep for further test work.
* treefile: Add a basic test for includes
Prep for adding an arch include test.
* treefile: Support `arch-include`
A long time ago we added architecture-specific package lists
via e.g. `packages-ppc64le`. Much more recently we added
support for having the `include` key be a list - multiple includes.
By combining these two and supporting architecture-conditional includes,
we've effectively added architecture-conditionals to *all* keys.
Notably we want this for Fedora CoreOS today which is using
`remove-from-packages` on `grub2-tools` which isn't present on
s390x.
* ci: Bump cosa build timeout
Looks like another OpenStack perf regression.
Currently [zincati](https://github.com/coreos/zincati/) executes
`rpm-ostree deploy` via the CLI - that just shows up as `cli` as
an agent. This makes it easier to highlight the fact that it's
actually zincati driving things.
Closes: #1880
Approved by: lucab
Use g_shell_quote to quote the value set for OSTREE_VERSION in
/etc/os-release as this is an arbitrary string set at compose time that
may contain whitespace or other special characters.
This edge case was found in [0] as the compose are built with the
following command:
$ rpm-ostree compose tree \
--repo="repo" \
--cachedir="cache" \
--add-metadata-string="version=Kinoite 30.23" \
"fedora-kinoite.yaml"
[0] https://discussion.fedoraproject.org/t/kinoite-a-kde-and-now-xfce-version-of-fedora-silverblue/147/95
Signed-off-by: Timothée Ravier <tim@siosm.fr>
Closes: #1873
Approved by: jlebon
I think we're in a good position now for FCOS enablement, and there are
a bunch of fixes we should get out, such as the zstd one.
Closes: #1875
Approved by: cgwalters
This may seem like a backflip on #1829, but there's a common theme here:
in a promotion workflow, the parent (or lack of parent) of a commit is
an important parameter, so we need full flexibility in configuring it.
But again, like #1829, we still want e.g. change detection, versioning,
and various optimizations to happen on whatever the latest commit on
that ref is in the build repo.
Closes: #1871
Approved by: cgwalters
