Currently the user has 2 sets of jobs that can be triggered on a GitLab
pipeline.
- to trigger all defconfigs, all runtime tests and all check-* jobs:
$ git tag <name>
$ git push gitlab <name> # currently 260 jobs
- to trigger only the check-* jobs:
$ git push gitlab HEAD:<name> # currently 4 jobs
This is not much versatile, so the user ends up hand-editing the
.gitlab-ci.yml in order to trigger some subsets, even the common ones,
for instance all runtime tests.
Add 2 more subsets that can be triggered based on the name of the
branch pushed.
- to trigger all defconfigs and all check-* jobs:
$ git push gitlab HEAD:<name>-defconfigs # currently 192 jobs
- to trigger all runtime tests and all check-* jobs:
$ git push gitlab HEAD:<name>-runtime-tests # currently 72 jobs
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
only:
- triggers
- tags
+ - /-defconfigs$/
script: *defconfig_script
artifacts:
when: always
only:
- triggers
- tags
+ - /-runtime-tests$/
# Keep build directories so the rootfs can be an artifact of the job. The
# runner will clean up those files for us.
# Multiply every emulator timeout by 10 to avoid sporadic failures in
only:
- triggers
- tags
+ - /-defconfigs$/
script: *defconfig_script
artifacts:
when: always
only:
- triggers
- tags
+ - /-runtime-tests$/
# Keep build directories so the rootfs can be an artifact of the job. The
# runner will clean up those files for us.
# Multiply every emulator timeout by 10 to avoid sporadic failures in