Re: Serious doubts about Gitlab CI

[Philippe Mathieu-Daudé]

On 3/19/21 11:59 AM, Paolo Bonzini wrote:
> On 19/03/21 11:18, Andrew Jones wrote:
>>> Yikes, that is 41 hours per CI run. I wonder if GitLab's CI minutes are
>>> on slow machines or if we'll hit the same issue with dedicated runners.
>>> It seems like CI optimization will be necessary...
>>>
>> We need to reduce the amount of CI we do, not only because we can't
>> afford
>> it, but because it's wasteful. I hate to think of all the kWhs spent
>> testing the exact same code in the exact same way, since everyone runs
>> everything with a simple 'git push'.
> 
> Yes, I thought the same.
> 
>> IMHO, 'git push' shouldn't trigger
>> anything. Starting CI should be an explicit step.

* tests/acceptance: Only run tests tagged 'gating-ci' on GitLab CI
https://www.mail-archive.com/qemu-devel@nongnu.org/msg756464.html

* gitlab-ci: Allow forks to select & restrict build jobs
https://www.mail-archive.com/qemu-devel@nongnu.org/msg758331.html

> It is possible to do that on a project that uses merge requests, for
> example like this:
> 
> workflow:
>   rules:
>     - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
>     - if: '$CI_COMMIT_BRANCH
>       when: never
> 
> For us it's a bit more complicated (no merge requests).
> 
> Another common feature is failing the pipeline immediately if one of the
> jobs fail, but GitLab does not support it
> (https://gitlab.com/gitlab-org/gitlab/-/issues/23605).
> 
>> Also, the default CI
>> should only trigger tests associated with the code changed. One should
>> have to explicitly trigger a complete CI when they deem it worthwhile.
> 
> This is interesting.  We could add a stage that looks for changed files
> using "git diff" and sets some variables (e.g. softmmu, user, TCG,
> various targets) based on the results.  Then you use those to skip some
> jobs or some tests, for example skipping check-tcg.  See
> https://docs.gitlab.com/ee/ci/variables/#inherit-cicd-variables for more
> information.
> 
> Paolo
> 
>