Hello all,
Does the cmake plugin support invoking ctest after the build, but before the install?
If not, any chance it could be added? And in the meantime, any advice on how to achieve this outcome?
Thanks & best wishes,
-- JoeIf you’re happy for the tests to run after “make install” (which copies files to a part-specific staging directory), you could use the install: stanza. Something like:
install: |
set -x
ctest --verbose
Now if the tests fail, this should fail the build step of your part.
Ah, nice! I’d assumed the install: scriptlet replaced the usual install stage, rather than following it (by analogy to the build: scriptlet). I’ll give that a go.
We are fixing the language here, technically and for historical reasons build and install were part of build and there is no such install stage. We will be working on actually naming the scripts pre-<stage> and post-<stage> for every step in the lifecycle and properly introducing install as a stage for a plugin to implement. All this, in a backwards compatible way as well.
Yes, I remember these goals being discussed. Great to hear! Meanwhile I’ll have a go at using install: for my use-case 
Seems to work nicely. The patch I came up with in the end uses both the install: scriptlet and a separate part to install all the dependencies required for the ctest call (including both regular build-packages and the need to pip install one package not in Ubuntu):
https://github.com/ldc-developers/ldc2.snap/pull/35
Thanks very much for the help/advice! 
It looks like you removed the set -x call from my suggested version, so you might want to check that test failures actually stop your build.
When I was playing around with scriptlets in one of my projects I noticed this shell flag wasn’t set, which means that exit statuses of commands are not checked. With -x, a failed command in the shell script causes the script to stop with an error return value.
Yes, I’m in two minds about this myself. Without set -x the build still fails if any test case fails, but not immediately on failure, only when ctest exits. I need to confirm if using set -x will cause immediate exit at the first test failure (which might be preferable).
set -x shouldn’t have any effect on what is run within ctest itself (if any of your tests involve the shell, they will be running different instances of it). This is just going to check the exit status of ctest itself.
Ah, so there is a potential concern that just because ctest fails, does not mean that the scriptlet script is guaranteed to return a failure status (even though it clearly does at the moment)?
With set -x this is better guaranteed, of course.
Right. Snapcraft just pastes your scriptlet into a shell script file and executes it. By default, the shell will not check the exit status of the commands it executes.
This is a bit surprising, so I think there might be some value in changing Snapcraft to turn on -x by default.
Wait a moment, I think I’ve been totally mixing up my set flags. -x doesn’t affect the exit status at all, it just ensures that the commands are traced as they are issued: https://ss64.com/bash/set.html
set -e is the one that results in immediate exit if anything in the script fails.
Sorry about that: I got the flags mixed up. I remembered running into this problem with one of my projects and the first I found had set -x in one of its scriptlets. The other where I actually ran into this problem was using set -eux (-u adds a bit more safety by making it an error to reference a non-existent environment variable).
Unfortunately, this setup seems to be running into trouble in the launchpad build daemon. It has run absolutely fine with local snapcraft cleanbuild calls, but seems to pause indefinitely when built by launchpad-buildd.
Interestingly, it seems to be during unittests of the D standard library’s curl module that things freeze up. Is there anything in launchpad-buildd's operations that might get in the way of curl requests, even if they’re only running against a local entity?