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>
