I am trying to set up a gitlab CI pipeline for an established project. We have many short tests to run and the overhead of spinning up a docker container and pulling the repository for each test takes about 10 times longer than the test itself. I am looking for a way to run many small tests like this and still have them each be visible as separate jobs in my pipeline. I have looked in to running multiple commands in one job but can’t find any way to report the result of each command as its own output. I have also looked in to running multiple jobs in the same docker container to avoid the startup overhead, but as far as I can see this is not supported by gitlab CI.
I am a relative novice with gitlab CI, so I may be overlooking something obvious. Any help or advice would be greatly appreciated.
Thank you,
Mitchell
I have the same question as you. In my case, all 3 stages (installing dependencies, linting and testing) take no more than 2 minutes when run sequentially on one single GitLab runner. In the lining stage, there are 5 linting jobs that each put a lot of overhead provisioning a new Docker container, fetching the git repository, downloading and uploading cache and installing Node.js packages from cache.
There are no dependencies between stages and jobs in my situation.
I think it would be a lot better if there was a possibility to separate all commands into logical groups (under a single stage and job) which then GitLab can parse and output in the UI as separate tasks (the same way it does with showing jobs in the jobs overview). Then one can get the same UI benefits as when running multiple jobs.
If somebody has any ideas of any additional benefits of the current configuration in my case except the nice UI overview that jobs provide in my case, please share them.
Gitlab can parse and show Unit Test results in the junit XML format (not to be confused with xunit).
If you manage to build such an XML(either because your tool supports it or you generate one yourself) you could use this to output details on your arbitrary Testset running in a single job.
Another solution could be to get rid of Docker and have a dedicated runner in an already completely prepared environment. Not my favourite solution since having the information about what environment is needed is no longer mandatory for the repo, which could lead to some fun if someone trys to start it up again after years of neglect. But it would work.