[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gitlab-ci for test jobs

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

> 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.


Deflector shields just came on, Captain.

Reply to: