Daniel Hilst
2bfad97348
Four fixes from @viniciusferrao's review plus the CI break his review predates. orig tarball version. dpkg looks for <source>_<upstream>.orig.tar.gz with no Debian revision, and the call site passed the full Version-Release. The rule now lives in BuildUtils::upstream_version and orig_tarball_name applies it, so the call site cannot get it wrong whichever string it is handed. Currently dormant -- every package is Format: 1.0, so the quilt branch does not run, which is why the differential build did not catch it. --dest could write to the filesystem root. Cwd::abs_path returns undef when a PARENT component is missing (a missing leaf is fine), and the caller interpolated that, so `--dest /no/such/parent/out` became `/debs` and `/xcat-core` at /. Replaced with BuildUtils::resolve_dest, which is rel2abs and purely lexical -- correct for an output directory that does not exist yet. Generated debian/control left behind. xCAT-genesis-scripts has no debian/control of its own; it is generated from control-<arch>. The cleanup restored only files that already existed, so the generated one stayed. Worse than dirty: ppc64el ran last, so the restore put back the amd64 BACKUP and the leftover was the wrong architecture's control, which a later single-arch build would have started from. with_prepared_tree now records created files and removes them. Verified by a real build: the checkout is byte-clean afterwards, matching the oracle. CI install step. build-ubunturepo wrote its repo to $curdir/../../xcat-core, which under GitHub's work/<repo>/<repo> layout IS $RUNNER_WORKSPACE, so install_xcat's `./mklocalrepo.sh` happened to be in the directory it chdir'd to. builddebs.pl writes inside the checkout instead -- that outside-the-checkout path is what used to rm -rf the tree -- so install_xcat now names the script by its real location and fails with a clear message if the build produced no repository. This is what reddened xcat_pr_test at 2m13s; the builder itself was fine (the exact CI invocation, `./builddebs.pl --force` with no --dest, returns 0 with all 14 packages). The executable bit was already fixed before the review landed. Both new helpers are tested and mutation-verified: not stripping the revision reddens 3 assertions, swapping rel2abs back to abs_path reddens 2. Equivalence re-measured after these changes -- all 14 packages identical to build-ubunturepo in control and in every non-changelog file by md5. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
xCAT-test/unit
Unit tests. These run against the source tree only -- no xCAT installation, no running daemons, no management node.
They are executed on every pull request by the xcat_test GitHub Actions workflow,
which calls run_unit_tests() in github_action_xcat_test.pl:
prove -r xCAT-test/unit
You can run exactly the same thing from a clean checkout:
cd <xcat-core checkout>
prove -r xCAT-test/unit
What belongs here
A test belongs in unit/ when everything it needs is in the checkout: plugin and
library sources, kickstart/preseed/subiquity templates, postscripts, packaging
metadata. Such a test asserts on rendered output or module logic and reaches the
repository root through FindBin:
use FindBin;
use lib "$FindBin::Bin/../../perl-xCAT";
use lib "$FindBin::Bin/../../xCAT-server/lib/perl";
Because of those FindBin paths the tests only work from a source tree. The copy
installed under /opt/xcat/share/xcat/tools/autotest/unit is not a substitute --
../.. resolves to /opt/xcat/share/xcat/tools there and the tests die or silently
skip. The CI takes a copy of the checkout before the build for this reason; see
preserve_source_tree().
What does not belong here
Anything that needs an installed xCAT, a populated /install, a real service binary
or a live daemon. Those go in ../integration and run on
a management node through xcattest. Both suites run on every pull request -- the
workflow installs xCAT on the runner and then runs the ci_test cases against it --
so putting a test in integration/ does not cost it CI coverage. What differs is what
each suite is allowed to depend on, and that unit tests also run standalone from a
bare checkout with no xCAT at all.
The distinction matters because a test that needs an absent environment does not fail
-- it calls plan skip_all and reports as skipped. A handful of those in a suite of
several hundred assertions is easy to stop reading. Keeping the two kinds in separate
directories means a skip in unit/ is a real signal rather than routine noise.
Guarding on a source file, on the other hand, is fine and common here:
plan skip_all => "compute.subiquity.tmpl not found" unless -f $tmpl_path;
That guard never fires when the tree is intact.