Skip to content

tests: drop sudo from the test suite and the package CI job - #4663

Open
grandixximo wants to merge 1 commit into
LinuxCNC:masterfrom
grandixximo:ci-no-sudo
Open

grandixximo wants to merge 1 commit into
LinuxCNC:masterfrom
grandixximo:ci-no-sudo

Conversation

@grandixximo

Copy link
Copy Markdown
Contributor

As discussed in #4648: no sudo while running tests or building packages.

  • The ten tests that ran ${SUDO} halcompile --install use plain halcompile and an executable skip file ([ -z "$SYSTEM_BUILD" ]), like kins-frames and kins-jacobian already do: they run on RIP, where the install goes into the tree, and skip against installed packages.
  • All control files (Restrictions: sudo) are gone; relative-header-user only compiles and keeps running on packages.
  • runtests: no SUDO, no control handling, no -u. tests/README and writing-tests.adoc document the skip file instead.
  • package-arch: no sudo package, testrunner is not in the sudo group.

The sudo left in ci.yml is runner provisioning (apt, core_pattern sysctl), not build or test.

@BsAtHome one open point: nothing in tree passes -u, but an out-of-tree script that does now gets the usage text and exit 0 without running anything. Should I keep -u as an accepted no-op for a while, or is removing it fine?

Tests that installed a component with `${SUDO} halcompile --install`
now use plain halcompile and an executable skip file, so they run on RIP
and skip against installed packages. Remove SUDO, the control file
handling and -u from runtests, and sudo from the package-arch job.
@hdiethelm

Copy link
Copy Markdown
Contributor

Hmm, is it a good idea to skip all this tests with installed Debian packages?

sudo halcompile --install is something that could work with rip builds and fail with installed Debian package. Probably no one will notice this for some time.

Of course, it makes tests easier, I could drop 3a6b4a4

@grandixximo

Copy link
Copy Markdown
Contributor Author

The call on wether it is safe to skip them it's a call @BsAtHome already made a while ago, all new tests are already following this pattern as per his blocker, since the new pattern also simplifies the parallel testing, I just went back to fix the old tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants