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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Introduces an intermediate format for overlayfs storage, where
.wh-ostree. prefixed files will be converted into char 0:0
whiteout devices used by overlayfs to mark deletions across layers.
The CI scripts now uses a volume for the scratch directories
previously in /var/tmp otherwise we cannot create whiteout
devices into an overlayfs mounted filesystem.
Related-Issue: #2712
In https://github.com/ostreedev/ostree/pull/2633 I realized
that our CI only builds git of libostree or git of rust-bindings,
not git of both. And we definitely want to test the latter too,
so e.g. the Rust tests *also* become tests for changes to the C code.
There were some changes to the sys API for introspection fixes.
And add a feature for the current release, which is something
I'll add to the checklist for releases.
Make a copy of `man/html` to `docs/man` and then configure Jekyll to
include it verbatim like the API docs. A link is added to the main index
and the necessary commands are added to the github docs workflow.
The ubuntu-latest VMs are currently based on 20.04 (focal). In focal,
libseccomp2 doesn't know about the close_range syscall[1], but
g_spawn_sync in impish tries to use close_range since it's defined in
glibc. That causes libseccomp2 to return EPERM as it does for any
unknown syscalls. g_spawn_sync carries on silently instead of falling
back to other means of setting CLOEXEC on open FDs. Eventually it causes
some tests to hang since once side of a pipe is never closed. Remove
this when libseccomp2 in focal is updated or glib in impish handles the
EPERM better.
1. https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1944436Fixes: #2495
This adds build-time configuration logic to automatically detect
and switch between libfuse 2.x and 3.x.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Co-authored-by: Luca BRUNO <luca.bruno@coreos.com>
This is really the standard best practice, matching how
e.g. dpkg/rpm work, as well as most local development
environments (including mine) with e.g. `toolbox`.
Rather than use the release codename tags, use the release stage tags.
This way the configuration (theoretically) doesn't need to be updated
when new Debian and Ubuntu releases are made.
For Debian stable is used instead of buster and a testing (bullseye)
build is added. For Ubuntu, latest is used instead of focal for the
current LTS and rolling is used instead of groovy for the latest
release. This actually changes the Ubuntu build from groovy to hirsute.
Don't cancel all the jobs if one distro config fails. The jobs are
mostly independent, so we do want to let the others continue in case
the failure is isolated to that particular distro configuration.
This runs the test suite in various distros. The intention is to use
this to replace the Travis CI setup since it often has rate limit
failures.
Each configuration in the matrix runs in a Docker container, installs
system dependencies and then builds and tests ostree. The scripts are
basically copy and paste of the travis ones with some of the lesser used
features pruned out.
Some differences from the travis setup:
* OS details are gathered from `/etc/os-release` instead of being passed
in as environment variables.
* The scripts always assume the user is root and don't try to use
`sudo`.
* The `installcheck` test has been removed since ostree doesn't actually
use that. It could be added to run the installed tests or
`gnome-desktop-testing-runner` could just be called directly.
There should be enough flexibility to run other distros like Fedora,
Arch or Alpine. Another option would be to use the other build scripts
in ci/.
The ostree repo has read permissions set for workflows, which prevents
the documentation job from pushing the built docs to the gh-pages
branch. Raise the job's permissions to write for repo contents to allow
that.
Make a copy of `apidoc/html` to `docs/reference` and then tell Jekyll to
include it verbatim. This will include the gtk-doc API docs on the
static site. A link is added to the main index.
A script is added to do the copy (a symlink won't do) and is setup to
run before Jekyll in the GitHub workflow. Ideally this would be a local
Jekyll plugin to make the process automatic, but the github-pages gem
doesn't allow that.
This uses the Jekyll Actions GitHub action to push the rendered docs to
the gh-pages branch rather than GitHub's automated docs flow. That will
allow greater control over how the docs are generated. Pushing to the
gh-pages branch only happens on pushes to main. For pull requests, the
docs are only built.
This tweaks the release GH workflow further so that it only triggers
when the `configure.ac` file (which owns the version) changes.
Plus it properly checkouts the PR branch to avoid wrongly looking
at a synthetic merge commit.
