Philippe Mathieu-Daudé <f4...@amsat.org> writes:
> Forks run the same jobs than mainstream, which might be overkill.
> Allow them to easily rebase their custom set, while keeping using
> the mainstream templates, and ability to pick specific jobs from
> the mainstream set.
>
> To switch to your set, simply add your .gitlab-ci.yml as
> .gitlab-ci.d/${CI_PROJECT_NAMESPACE}.yml (where CI_PROJECT_NAMESPACE
> is your gitlab 'namespace', usually username). This file will be
> used instead of the default mainstream set.
>
> Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org>
> ---
> .gitlab-ci.yml | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 718c8e004be..35fd35075db 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -9,7 +9,12 @@ generate-config:
> paths:
> - generated-config.yml
> script:
> - - cp .gitlab-ci.d/qemu-project.yml generated-config.yml
> + - if test -e .gitlab-ci.d/${CI_PROJECT_NAMESPACE}.yml ;
> + then
> + cp .gitlab-ci.d/${CI_PROJECT_NAMESPACE}.yml generated-config.yml ;
> + else
> + cp .gitlab-ci.d/qemu-project.yml generated-config.yml ;
> + fi
This is going to be a little clunky. I can see a use for the static
forks that Danial proposes but I guess what is needed is a little
expressiveness. So how to express things like:
- I've only touched stuff in linux-user, so run only linux-user tests
- I'm working on KVM, run all KVM enabled builds and tests
- I've changed the core TCG code, run everything that exercises that
- I'm working on ARM, only build and run jobs that have ARM targets
This sounds like tags I guess but the documentation indicates they are
used for runner selection. Could we come up with a subset that could be
used to select from all our build fragments when constructing the
generated-config? I could even imagine a script analysing a diffstat and
guessing the tags based on that.
I think we should define a minimum set of lightweight smoke tests that
get the most bang for buck for catching sillies. I think checkpatch and
dco checking should probably be in there - and maybe one of the bog
standard build everything builds (maybe a random ../configure; make;
make check on one of the supported LTS targets).
Then there is the question of defaults. Should we default to a minimised
set unless asked or should the default be the full fat run everything?
We could I guess only switch to running everything for the staging
branch and anything that is associated with a tag or a branch that has
pull in the name?
>
> generate-pipeline:
> stage: test
--
Alex Bennée
