Hi Ross On Sat, Oct 13, 2018 at 04:38:32PM -0700, Ross Vandegrift wrote: > First complete pass at a framework for running tests is here: > https://salsa.debian.org/cloud-team/debian-cloud-images/merge_requests/36 > It's working, you can see the last run at: > https://salsa.debian.org/rvandegrift-guest/debian-cloud-images/pipelines/21750
Yeah. There are nice echo calls. Will take a look at the code changes later. > This is the simplest config I could find that has a separate test job for each > build job. It's complex and verbose. Makes it hard to know that all of the > cases are covered. Yeah, I know that Gitlab does not really help for such cases. > One alternative: extend the .build job scipt to run tests after FAI. The > benefit: a new build job automatically gets tests run without manually > creating > a new job. The downside: if a job fails, you have to dig through logs to > determine if the build failed or if the tests failed. Please don't. It also makes it harder to get results from the artifacts. > If we go with separate jobs, we could add a CI-linting stage before the build. > This could check the pipline to ensure e.g., every build has a test, only > official builds get run on casulana, etc. We could go for a generated file approach. Sure, you need to be careful then, but I think the advantages are greater. It would also avoid some gitlab-runner limitations, like non-recursive variable expansion and allow adding the git-sha1 to the dev build version. Bastian -- Deflector shields just came on, Captain.
