fix(xcat-core): run the integration testcase on pull requests too

The integration testcase was added without the ci_test label on the
grounds that the pull request workflow has no management node. That was
wrong: github_action_xcat_test.pl builds xCAT, installs it, runs
setup-local-client.sh and chtab, and leaves xcatd running, which makes
the runner a single node management node. Running the ci_test cases
against it is exactly what the fast regression stage already does.

Label the case ci_test so the integration tests get pull request
coverage as well. This also unlocks a test that had been skipping for a
fixable reason: each case is invoked through sudo, and
dhcp_kea_config_validation.t skips only because /etc/kea is not writable
by the unprivileged runner user, so as root it validates instead of
skipping.

Running the integration suite as root and the unit suite unprivileged is
the right way round. Integration tests legitimately need to write to
places like /etc/kea, whereas running the unit tests as root would let
permission-related assertions pass for the wrong reason.

Correct both READMEs, which carried the mistaken claim that the
integration tests do not run in CI.

Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>

xCAT-test/autotest/testcase/integration/cases0

@@ -1,7 +1,7 @@
 start:integration_tests
 description:Run the xCAT-test integration tests (xCAT-test/integration) against the installed management node
 os:Linux
-label:mn_only,integration
+label:mn_only,ci_test,integration
 cmd:prove -I/opt/xcat/lib/perl -I/opt/xcat/lib/perl/xCAT -r /opt/xcat/share/xcat/tools/autotest/integration
 check:rc==0
 end

xCAT-test/integration/README.md

@@ -4,8 +4,7 @@ Integration tests. These run against an **installed management node** -- they ne
 real xCAT installation, and depending on the test a populated `/install`, a service
 binary they can execute, or a live daemon.
 
-They are *not* run by the GitHub Actions pull request workflow, which has no
-management node. They are driven by `xcattest` through the testcase in
+They are driven by `xcattest` through the testcase in
 `../autotest/testcase/integration/`, which proves the copy installed by the
 `xcat-test` package:
 
@@ -14,15 +13,26 @@ prove -I/opt/xcat/lib/perl -I/opt/xcat/lib/perl/xCAT \
       -r /opt/xcat/share/xcat/tools/autotest/integration
 ```
 
-Run the case on an MN with:
+Run the case by hand on an MN with:
 
 ```
 xcattest -f <cluster.conf> -t integration_tests
 ```
 
+The case carries the `ci_test` label, so it also runs on every pull request: the
+`xcat_test` GitHub Actions workflow installs and configures xCAT on the runner, which
+makes that runner a (single node) management node, and then runs every `ci_test` case
+against it.
+
 Note the `-I` flags: unlike the unit tests these run from the installed location, so
 they pick up xCAT modules from `/opt/xcat/lib/perl` rather than from a source tree.
 
+Note also that `github_action_xcat_test.pl` invokes each case through `sudo`, so in CI
+these tests run as **root** while the unit tests run unprivileged. That is the right
+way round -- integration tests legitimately need to write to places like `/etc/kea`,
+whereas running the unit tests as root would let permission-related assertions pass
+for the wrong reason.
+
 ## What belongs here
 
 A test belongs in `integration/` when it needs something the checkout cannot provide:
@@ -40,6 +50,11 @@ legitimately lacks the dependency -- an MN with no Kea installed should skip the
 tests, not go red. A skip in this directory is therefore expected and normal, which is
 precisely why these tests do not belong alongside the unit tests.
 
+Which tests actually run consequently varies by node. On a GitHub runner, for example,
+`/install` is empty so `copycds_packages_integrity.t` skips, while
+`dhcp_kea_config_validation.t` does run because the case executes as root and can
+therefore validate from `/etc/kea`.
+
 `dhcp_kea_control_agent_smoke.t` is opt-in on top of that:
 
 ```perl

xCAT-test/unit/README.md

@@ -40,7 +40,11 @@ skip. The CI takes a copy of the checkout before the build for this reason; see
 
 Anything that needs an installed xCAT, a populated `/install`, a real service binary
 or a live daemon. Those go in [`../integration`](../integration/README.md) and run on
-a management node through `xcattest`.
+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