aboutsummaryrefslogtreecommitdiff
path: root/support/gnuconfig
diff options
context:
space:
mode:
authorGravatar Yann E. MORIN <yann.morin.1998@free.fr>2020-10-05 22:48:25 +0200
committerGravatar Thomas Petazzoni <thomas.petazzoni@bootlin.com>2020-10-06 15:38:48 +0200
commitcf8364f202352c8d5c64209aaf46fd98f0d7ef60 (patch)
tree984a1f9779a34952481e91124b68b3a81942dad1 /support/gnuconfig
parentf2a0da36ef4f529b2324324c23cc0f9a07e48ae6 (diff)
downloadbuildroot-cf8364f202352c8d5c64209aaf46fd98f0d7ef60.tar.gz
buildroot-cf8364f202352c8d5c64209aaf46fd98f0d7ef60.tar.bz2
support/scripts/generate-gitlab-ci-yml: rework generation of pipelines
Currently, we handle three kinds of tests: basic, defconfig, and runtime, and we treat them totally independently ones from the others. Except for the basic tests that are ignored when defconfig or runtime tests are explicitly requested. The basic tests are also run systematically on all our reference branches: master, next (when it exists), and the maintenance branches: YYYY.MM.x. Furthermore, we can see that the conditions to run each set of tests are very similar, with only the explicit queries differing by name. Rework the script so that the conditions are expressed only once, and each set of tests is decided for each condition. This makes it easier to decide what tests should run under what conditions. Using GitLab-CI's schedules, with a variable expressing the actual test to run, would seem the obvious choice to trigger the pipelines. However, a schedule is configured for a specific branch, which means we would need one schedule per branch we want to build per test cases we want to run, *and* that we update those schedules when we add/remove branches (e.g. when we open/close 'next', or a maintenance branch). This is not very nice, as it requires some manual tweaking and twiddling on the web UI. Instead, we resort to using triggers, that will be triggered from a cronjob on some server. Using a cronjiob allows us to more easily manage the branches we want to test and test cases we want to run, to more easily spread the load over the week, etc... Note: triggering a pipeline can be done with a simple curl invocation: $ curl -X POST \ -F "token=${YOUR_TOKEN}" \ -F "ref=${BRANCH_TO_TEST}" \ -F "variables[BR_SCHEDULE_JOBS]=${TEST_TO_RUN}" \ "https://gitlab.com/api/v4/projects/${YOUR_PROJECT_ID}/trigger/pipeline" Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Romain Naour <romain.naour@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Diffstat (limited to 'support/gnuconfig')
0 files changed, 0 insertions, 0 deletions