mirror of
https://github.com/xcat2/xcat-core.git
synced 2026-09-25 09:14:05 +00:00
Daniel Hilst
c8a57880d6
Killing the command is not killing the build. sh() ran the command through /bin/sh, and cancellation signalled that shell alone -- but dpkg-buildpackage starts workers of its own, and those survive their shell. The lock was then released while they were still writing debian/changelog and debian/control, which is the state the lock exists to prevent: the next build takes the checkout and the two rewrite it together. The command now runs in its own process group, so cancellation can take all of it. Both sides call setpgid, so neither depends on which runs first, and INT and TERM are blocked across the fork so cancellation cannot land in the window before the group exists. Cancellation escalates from the caught signal to KILL, and then CHECKS: a shell that has exited is not a build that has stopped, so it waits for the whole group to disappear rather than for the leader to be reaped. If the group is still there after that, the locks are RETAINED and the process exits non-zero. Releasing a lock while a worker may still be writing is worse than leaving a lock behind for a person to clear -- the first corrupts a build, the second stops one. cancel_build ignores INT and TERM while it runs, so a second Ctrl-C cannot interrupt the cleanup half way and release the lock early. sh() also reports a signalled command as 128+signal instead of 0. $? >> 8 is zero for a child killed by a signal, so a build stopped mid-way looked to its caller like one that had succeeded. Two cases added to builddebs_lock_cancellation.t: a build whose worker is a grandchild, and a command killed by a signal. Verified by signalling the pid instead of the group, which leaves the worker running and turns the first red. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
xCAT-test
Unit tests that run from the source checkout are split by implementation language:
| Test type | Location | Runner |
|---|---|---|
| Perl unit tests | xCAT-test/unit/*.t |
prove -r xCAT-test/unit |
| Shell unit tests | xCAT-test/bats/*.bats |
bats -r xCAT-test/bats |
| CLI functional tests | xCAT-test/autotest/testcase/ and xCAT-test/autotest/bundle/ |
xcattest -f <cluster.conf> -t <case> or xcattest -f <cluster.conf> -b <bundle> |
Use Perl .t tests for Perl modules, Perl scripts, templates, and repository
artifacts. Use BATS tests for shell-script behavior that can be exercised from
the checkout by sourcing a shell library or script and shadowing external
commands.
Shell behavior should not be tested by Perl tests that grep shell source. Put
those tests under xCAT-test/bats instead.
See unit/README.md and bats/README.md for the detailed rules for
each unit-test suite.