A few lines above, we disable pipelines for farm disables, but we were
missing a condition to run the container & build jobs when re-enabling
a farm, leading to invalid pipelines where test jobs for that farm are
created but the container & build jobs are missing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26809>
Use the CustomLogger class and CLI tool to create strutured logs
for poe scripts which are used by broadcom and nouveau jobs.
Renamed stage lint to code-validation and added python-test job
which runs the tests for structured and customer logger to ci.
Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25179>
All these jobs are redundant and a waste of resources:
- the containers have already been built & pushed in the merge pipeline
- the mesa build variants have already all passed
- the driver tests have already all passed
None of these jobs are doing anything useful in this pipeline, but it
costs a factor of 2x to our infrastructure, so let's remove them.
In other words, the only job left in the post-merge pipeline is the
`pages` job that deploys the update to the website.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26451>
There is close to zero work needed to execute this job.
Should speed up the initial process of entering into pipeline tree
and also provide an opportunity for `aarch64` runners to engage sooner,
even when x86_64 machines are loaded.
Acked-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26125>
We need update kernel often. We need test kernel changes often.
Introduced `KERNEL_EXTERNAL_TAG` to differ between `KERNEL_TAG` which is
also used to rebuild the containers. We don't need rebuild containers
for the external kernel, so this way we don't have to.
Updating kernel goes wruuuuuum.
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23563>
This reverts commit fac60c140b.
Turns out there are pipelines that do not create any other jobs, and
Marge requires a pipeline to pass, which means a pipeline needs to
exist, which means a job needs to always exist.
There is no reason `sanity` would be the one, but it's there so let's
just use it instead of making another one.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26080>
These are not real rules, they are just strings that have an anchor that
can be referenced elsewhere in this file.
Having these fake bits in here is confusing, as revealed by the
reactions from the first version of this commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25920>
Turns out I was right the first time, I was just missing that this
should only be done in MRs, which @daniels added in 16527f6ffd.
Without this, a "farm re-enable" pipeline will run all the jobs for that
farm, but will have none of the container & build jobs to support these
tests.
This reverts commit 1c3097225a.
Fixes: 1c3097225a ("ci: don't run everything just because a farm gets re-enabled")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25243>
Make sure we don't end up with manual container jobs in MR pipelines,
because they'll never start. This cleans up the container and build
rules so always 'do the right thing' on MRs (container+build if
required, nothing if not) and user branches (all manual).
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25219>
For consistency, make our 'when: never' rules be the first rules to
match any job, either build or container.
Otherwise we could end up with some jobs having when: never and others
having when: manual.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25205>
The argument for keeping this duplicate was to not affect
the ci_run_n_monitor script (which by default picked the pipeline in the
user's fork), but the script already supported specifying
a `--pipeline-url` to support that use-case, and it now automatically
picks the MR pipeline if there is no fork pipeline.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25154>
At least these two can be easily used in bare-metal or Labgrid setups.
Currently I already have MR for implementing these for Labgrid.
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24665>
When Marge rebases, it creates two pipelines, one in the author's account
due to the rebase and another one in the target account due to the merge
request event. Depending on the order they appear, Marge erroneously
check the author's pipeline, and since it doesn't have the rights to
start this pipeline, Marge fails to merge because it timed out (since the
pipeline never got run).
Fix this by disabling the author's pipeline (source of type "push") when
a merge request is open.
We only disable when the pipeline is triggered by marge to not affect
running ci_run_n_monitor.py script
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24730>
This bring visible speedup while preparing the rootfs and containers.
Acked-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Acked-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24079>
Suggested-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Eric Engestrom <eric@igalia.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Acked-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23774>
That file has become a bit of the new `.gitlab-ci.yml` with just about
everything in there, but a lot of its content doesn't need to be in the
same file anymore now that `!reference` exists.
Signed-off-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24090>
This allows dynamically setting the priority to avoid starving Marge.
Signed-off-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23976>
farm rules are placed on test-source-dep.yml, so move it there.
This is also useful when trying to re-use the container/gitlab-ci.yml to
other workflows without running the jobs.
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23731>
- Disable farm with `git mv .ci-farm{,-disabled}/$farm_name`.
- Re-enable farm with `git mv .ci-farm{-disabled,}/$farm_name`.
NEVER MIX FARM MAINTENANCE WITH ANY OTHER CHANGE IN THE SAME MERGE REQUEST!
Reviewed-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Acked-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23629>
Rather than always retrying, only retry jobs on a limited set of causes.
This notably excludes retries when a job is stuck due to lack of runners
to schedule it; if we can't get a slot on a runner in time, there's no
reason to try again, since our window of opportunity has gone.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23108>
