Wherever it makes sense, save the logs as artifacts when something
fails (most likely the main step with real tests).
Signed-off-by: David Sterba <dsterba@suse.com>
Now docker hub images can be pulled for build tests (sources are
downloaded) and this is faster than rebuilding them each time so this
can be enabled for all ci/* and devel branches.
Signed-off-by: David Sterba <dsterba@suse.com>
Add a possibility to test branches independent of devel, the pattern is
prefix "ci/" or "CI/".
[ci skip]
Signed-off-by: David Sterba <dsterba@suse.com>
The CI test uses openssl 3.2 but it still hasn't made it to Tumbleweed,
it's still waiting in the queue. It'll be enabled again.
Signed-off-by: David Sterba <dsterba@suse.com>
The convert tests weren't enabled in the CI due to some problems that
seem to be fixed now. Add it to the default and coverage workflows, the
run time is about 2 minutes which is acceptable for coverage and for
devel it's running in parallel.
Signed-off-by: David Sterba <dsterba@suse.com>
With the recent updates to documentation build the theme must be now
installed as a package. Disable building documentation in all workflows
that do functional tests.
Signed-off-by: David Sterba <dsterba@suse.com>
There are several APIs that have tests, add a single build target for
convenience and enable that in the CI.
Signed-off-by: David Sterba <dsterba@suse.com>
https://www.openssl.org/ Is a well known cryptography library and since
freshly released version 3.2 it also supports variable digest size of
blake2b, so we can now add it among the crypto providers.
Configure with --with-crypto=openssl.
Signed-off-by: David Sterba <dsterba@suse.com>
https://botan.randombit.net/ Botan is a cryptography library with C
bindings and provides what we need (sha256 and blake2b), among many
others. Add it to the list of crypto backends if somebody wants to use
it.
Currently the version 2.19 is the latest one. Botan3 3.2.0 exists but
does not seem to be widely available in distros yet.
Configure with --with-crypto=botan.
Signed-off-by: David Sterba <dsterba@suse.com>
We can run more tests in parallel, the overall CI run time will be
shorter (from 12m to 5m) at the cost of building the same sources.
Also build documentation only once.
Signed-off-by: David Sterba <dsterba@suse.com>
The tests are run in one job, we can make it parallel by grouping
related tests together.
- musl test, using docker, does not have to wait for build
- simple tests, library, ioctl, api, ...
- the rest are functional tests
Signed-off-by: David Sterba <dsterba@suse.com>
We can speed up the CI tests by running them as separate build jobs,
they only need to checkout the sources.
Signed-off-by: David Sterba <dsterba@suse.com>
The release-test branch is used for pre-release checks so don't pollute
the workflows list with unverified builds. The static build checks will
be done within the other workflows but no binaries need to be published.
Signed-off-by: David Sterba <dsterba@suse.com>
Needed to work:
- install github app Codecov, accept permissions
- copy token from codecov.io to repository secrets
- allow actions permissions to run either verified marketplace creators
or list codecov/codecov-action@*
- set up repository as active on codecov.io, watch results eg.
https://app.codecov.io/gh/kdave/btrfs-progs/tree/coverage-test/
Signed-off-by: David Sterba <dsterba@suse.com>
On relese tests also check all the backends, use Tumbleweed as it's
known to work there and provide all supported library versions.
Signed-off-by: David Sterba <dsterba@suse.com>
Run release tests after pushing master branch to verify that everything
is ok, also trigger the static build so there are binaries built with
the new version tag.
Signed-off-by: David Sterba <dsterba@suse.com>
More complete test coverage:
- json an string table formatters
- fuzz tests (no mount)
- libbtrfs build test
- libbtrfsutil python test
- ioctl build test
- hash tests
Signed-off-by: David Sterba <dsterba@suse.com>
Calculate checksums for static binaries that are published as release
artifacts. Do that when they're built in the workflow so the checksum
appears in the build log and also provide the artifacts of the checksums
so they can be published along the releases.
Signed-off-by: David Sterba <dsterba@suse.com>
Build static binaries (published as artifacts):
- btrfs.static - the main tool
- btrfs.box.static - all-in-one tool (functionality selected by file name)
There are a few problems:
- unstable URL, i.e. not one location to get the binaries from, multiple
steps need on web or by using API
- downloaded files are in .zip (compression cannot be disabled with
upload-artifact@v3)
- permissions of the file inside .zip are lost, manual chmod needed
after extraction
- artifacts can be downloaded only for logged users
Issue: #593
Signed-off-by: David Sterba <dsterba@suse.com>
For a release test check that all compatibility build targets work. This
may take long as it's pulling lots of data (no caching yet) so it's not
run on devel.
Signed-off-by: David Sterba <dsterba@suse.com>
Add basic build tests and runtime tests devel, triggered by branch push.
For workflow testing there's a stub triggered by push of devel-ci.
Signed-off-by: David Sterba <dsterba@suse.com>
David Sterba