With all jobs now depending on check-trigger we can do the evaluations
there and set some variables that can be reused later.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Here we use a check-trigger job that all the others depend on, which
should prevent duplicate workflows starting a bit more elegantly than
killing one of them with the concurrency checker.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Add concurrency control to trigger workflow to cancel in-progress builds
when new events (like adding ci:main label) occur on the same PR. This
prevents resource waste from duplicate builds and handles the common
workflow where developers add the ci:main label after PR creation.
Fixes#1154
This branch can be used to test push events which is especially
useful when working on the CI infrastructure.
Signed-off-by: Richard Alpe <richard@bit42.se>
There are 2 main reasons for this:
1) It's almost impossible to write complex logical expressions in GH
workflows. I wanted to pass "" as flavor when not building _minimal.
So that the end target string would become TARGET + FLAVOR where
FLAVOR is empty, making it x86_64 for example.
As it turns out "" is false in GH workflow logical expressions, this
in conjunction with the limitations the interpreter has made it hard
to actually write sane expressions in the "with:" variables when
calling downstream jobs via workflow calls.
Here's an example of what I was trying to do and could not:
with:
flavor: ${{ (
github.event_name == 'pull_request' &&
contains(github.event.pull_request.labels.*.name, 'ci:main')
) && '' || '_minimal' }}
As '' is false, the first sets of expressions always evaluates to
false making the string "_minimal". I tried bracing this in various
ways and to use "null" or various JSON objects, all in vain.
2) It reduces complexity instead of adding additional.
Signed-off-by: Richard Alpe <richard@bit42.se>
Redesign how GH actions are triggered. This new design uses a
self-trigger to start jobs which are only started via workflow_calls.
The main benefit of this is to be able to start workflows from various
Infix Spins without needing to duplicate the workflow files in them.
Upcoming patches are intended to parameterize to allow Spins to pass
different architectures, brand names and such.
Signed-off-by: Richard Alpe <richard@bit42.se>
Joachim Wiberg