| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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`.
|
|
|
|
|
| |
Move the existing docs permissions stanza to the top of the workflow for
consistency.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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/.
|
|
|
|
|
| |
This workflow is specific to using rust and not just the general test
suite.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Since we now have a toplevel workspace, just use that.
|
|
|
|
|
| |
Let's dip our toes in GH Actions (specifically aiming to migrate
away from Travis).
|
|\
| |
| | |
templates: add release-checklist
|
| |
| |
| |
| | |
This collects all release steps in a release-checklist template.
|
|/
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This adds an additional condition in order to run sanity check all
PRs starting with `Release` (case-insensitive).
|
|
This adds a GitHub action in order to run ci-release-build.sh on
release PRs (detected via the `kind/release` label).
|