2023-02-27 10:05:59 +08:00
|
|
|
workflow:
|
|
|
|
rules:
|
2023-07-04 00:37:46 +08:00
|
|
|
# merge pipeline
|
2023-02-27 10:05:59 +08:00
|
|
|
- if: $GITLAB_USER_LOGIN == "marge-bot" && $CI_COMMIT_BRANCH == null
|
|
|
|
variables:
|
|
|
|
MESA_CI_PERFORMANCE_ENABLED: 1
|
2023-07-04 00:30:38 +08:00
|
|
|
VALVE_INFRA_VANGOGH_JOB_PRIORITY: "" # Empty tags are ignored by gitlab
|
2023-07-04 00:37:46 +08:00
|
|
|
# post-merge pipeline
|
2023-03-09 19:36:25 +08:00
|
|
|
- if: $GITLAB_USER_LOGIN == "marge-bot" && $CI_COMMIT_BRANCH
|
|
|
|
variables:
|
|
|
|
LAVA_JOB_PRIORITY: 40
|
2023-07-04 00:30:38 +08:00
|
|
|
VALVE_INFRA_VANGOGH_JOB_PRIORITY: priority:low
|
2023-07-04 00:37:46 +08:00
|
|
|
# any other pipeline
|
2023-03-09 19:36:25 +08:00
|
|
|
- if: $GITLAB_USER_LOGIN != "marge-bot"
|
|
|
|
variables:
|
|
|
|
LAVA_JOB_PRIORITY: 50
|
2023-07-04 00:30:38 +08:00
|
|
|
VALVE_INFRA_VANGOGH_JOB_PRIORITY: priority:low
|
2023-02-27 10:05:59 +08:00
|
|
|
- when: always
|
|
|
|
|
2019-01-20 19:21:45 +08:00
|
|
|
variables:
|
2020-03-07 05:23:20 +08:00
|
|
|
FDO_UPSTREAM_REPO: mesa/mesa
|
2022-09-07 19:38:36 +08:00
|
|
|
MESA_TEMPLATES_COMMIT: &ci-templates-commit d5aa3941aa03c2f716595116354fb81eb8012acb
|
CI: reduce bandwidth for git pull
Over the last 7 days, git pulls represented a total of 1.7 TB.
On those 1.7 TB, we can see:
- ~300 GB for the CI farm on hetzner
- ~730 GB for the CI farm on packet.net
- ~680 GB for the rest of the world
We can not really change the rest of the world*, but we can
certainly reduce the egress costs towards our CI farms.
Right now, the gitlab runners are not doing a good job at
caching the git trees for the various jobs we make, and
we end up with a lot of cache-misses. A typical pipeline
ends up with a good 2.8GB of git pull data. (a compressed
archive of the mesa folder accounts for 280MB)
In this patch, we implemented what was suggested in
https://gitlab.com/gitlab-org/gitlab/-/issues/215591#note_334642576
- we host a brand new MinIO server on packet
- jobs can upload files on 2 locations:
* git-cache/<namespace>/<project>/<branch-name>.tar.gz
* artifacts/<namespace>/<project>/<pipeline-id>/
- the authorization is handled by gitlab with short tokens
valid only for the time of the job is running
- whenever a job runs, the runner are configured to execute
(eval) $CI_PRE_CLONE_SCRIPT
- this variable is set globally to download the current cache
from the MinIO packet server, unpack it and replace the
possibly out of date cache found on the runner
- then git fetch is run by the runner, and only the delta
between the upstream tree and the local tree gets pulled.
We can rebuild the git cache in a schedule job (once a day
seems sufficient), and then we can stop the cache miss
entirely.
First results showed that instead of pulling 280MB of data
in my fork, I got a pull of only 250KB. That should help us.
* arguably, there are other farms in the rest of the world, so
hopefully we can change those too.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5428>
2020-06-11 23:16:28 +08:00
|
|
|
CI_PRE_CLONE_SCRIPT: |-
|
|
|
|
set -o xtrace
|
2021-12-03 15:07:47 +08:00
|
|
|
wget -q -O download-git-cache.sh ${CI_PROJECT_URL}/-/raw/${CI_COMMIT_SHA}/.gitlab-ci/download-git-cache.sh
|
|
|
|
bash download-git-cache.sh
|
|
|
|
rm download-git-cache.sh
|
CI: reduce bandwidth for git pull
Over the last 7 days, git pulls represented a total of 1.7 TB.
On those 1.7 TB, we can see:
- ~300 GB for the CI farm on hetzner
- ~730 GB for the CI farm on packet.net
- ~680 GB for the rest of the world
We can not really change the rest of the world*, but we can
certainly reduce the egress costs towards our CI farms.
Right now, the gitlab runners are not doing a good job at
caching the git trees for the various jobs we make, and
we end up with a lot of cache-misses. A typical pipeline
ends up with a good 2.8GB of git pull data. (a compressed
archive of the mesa folder accounts for 280MB)
In this patch, we implemented what was suggested in
https://gitlab.com/gitlab-org/gitlab/-/issues/215591#note_334642576
- we host a brand new MinIO server on packet
- jobs can upload files on 2 locations:
* git-cache/<namespace>/<project>/<branch-name>.tar.gz
* artifacts/<namespace>/<project>/<pipeline-id>/
- the authorization is handled by gitlab with short tokens
valid only for the time of the job is running
- whenever a job runs, the runner are configured to execute
(eval) $CI_PRE_CLONE_SCRIPT
- this variable is set globally to download the current cache
from the MinIO packet server, unpack it and replace the
possibly out of date cache found on the runner
- then git fetch is run by the runner, and only the delta
between the upstream tree and the local tree gets pulled.
We can rebuild the git cache in a schedule job (once a day
seems sufficient), and then we can stop the cache miss
entirely.
First results showed that instead of pulling 280MB of data
in my fork, I got a pull of only 250KB. That should help us.
* arguably, there are other farms in the rest of the world, so
hopefully we can change those too.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5428>
2020-06-11 23:16:28 +08:00
|
|
|
set +o xtrace
|
2022-02-23 23:44:33 +08:00
|
|
|
CI_JOB_JWT_FILE: /minio_jwt
|
2023-06-08 23:38:22 +08:00
|
|
|
S3_HOST: s3.freedesktop.org
|
2021-06-10 23:24:48 +08:00
|
|
|
# per-pipeline artifact storage on MinIO
|
2023-06-08 23:38:22 +08:00
|
|
|
PIPELINE_ARTIFACTS_BASE: ${S3_HOST}/artifacts/${CI_PROJECT_PATH}/${CI_PIPELINE_ID}
|
2021-06-10 23:29:39 +08:00
|
|
|
# per-job artifact storage on MinIO
|
|
|
|
JOB_ARTIFACTS_BASE: ${PIPELINE_ARTIFACTS_BASE}/${CI_JOB_ID}
|
2023-06-10 11:16:56 +08:00
|
|
|
KERNEL_IMAGE_BASE: https://${S3_HOST}/mesa-lava/gfx-ci/linux/${KERNEL_TAG}
|
2021-06-12 17:19:36 +08:00
|
|
|
# reference images stored for traces
|
2023-06-08 23:38:22 +08:00
|
|
|
PIGLIT_REPLAY_REFERENCE_IMAGES_BASE: "${S3_HOST}/mesa-tracie-results/$FDO_UPSTREAM_REPO"
|
2023-06-15 16:49:40 +08:00
|
|
|
# For individual CI farm status see .ci-farms folder
|
|
|
|
# Disable farm with `git mv .ci-farms{,-disabled}/$farm_name`
|
|
|
|
# Re-enable farm with `git mv .ci-farms{-disabled,}/$farm_name`
|
|
|
|
# NEVER MIX FARM MAINTENANCE WITH ANY OTHER CHANGE IN THE SAME MERGE REQUEST!
|
2019-04-02 15:24:00 +08:00
|
|
|
|
2021-12-02 21:13:10 +08:00
|
|
|
default:
|
|
|
|
before_script:
|
2022-12-12 00:46:41 +08:00
|
|
|
- >
|
|
|
|
export SCRIPTS_DIR=$(mktemp -d) &&
|
|
|
|
curl -L -s --retry 4 -f --retry-all-errors --retry-delay 60 -O --output-dir "${SCRIPTS_DIR}" "${CI_PROJECT_URL}/-/raw/${CI_COMMIT_SHA}/.gitlab-ci/setup-test-env.sh" &&
|
|
|
|
. ${SCRIPTS_DIR}/setup-test-env.sh &&
|
|
|
|
echo -n "${CI_JOB_JWT}" > "${CI_JOB_JWT_FILE}" &&
|
|
|
|
unset CI_JOB_JWT # Unsetting vulnerable env variables
|
2021-12-02 21:13:10 +08:00
|
|
|
|
|
|
|
after_script:
|
|
|
|
- >
|
|
|
|
set +x
|
|
|
|
|
|
|
|
test -e "${CI_JOB_JWT_FILE}" &&
|
|
|
|
export CI_JOB_JWT="$(<${CI_JOB_JWT_FILE})" &&
|
|
|
|
rm "${CI_JOB_JWT_FILE}"
|
|
|
|
|
2023-03-04 03:26:52 +08:00
|
|
|
# Retry when job fails. Failed jobs can be found in the Mesa CI Daily Reports:
|
|
|
|
# https://gitlab.freedesktop.org/mesa/mesa/-/issues/?sort=created_date&state=opened&label_name%5B%5D=CI%20daily
|
2022-07-08 02:32:45 +08:00
|
|
|
retry:
|
2023-03-04 03:26:52 +08:00
|
|
|
max: 1
|
2023-05-18 22:32:35 +08:00
|
|
|
# Ignore runner_unsupported, stale_schedule, archived_failure, or
|
|
|
|
# unmet_prerequisites
|
|
|
|
when:
|
|
|
|
- api_failure
|
|
|
|
- runner_system_failure
|
|
|
|
- script_failure
|
|
|
|
- job_execution_timeout
|
|
|
|
- scheduler_failure
|
|
|
|
- data_integrity_failure
|
|
|
|
- unknown_failure
|
2022-07-08 02:32:45 +08:00
|
|
|
|
2019-04-02 15:24:00 +08:00
|
|
|
include:
|
2020-03-07 05:23:20 +08:00
|
|
|
- project: 'freedesktop/ci-templates'
|
2023-01-19 23:09:13 +08:00
|
|
|
ref: 16bc29078de5e0a067ff84a1a199a3760d3b3811
|
2020-11-25 00:02:13 +08:00
|
|
|
file:
|
2020-11-19 01:23:29 +08:00
|
|
|
- '/templates/ci-fairy.yml'
|
2020-12-03 00:37:16 +08:00
|
|
|
- project: 'freedesktop/ci-templates'
|
2020-12-16 01:02:04 +08:00
|
|
|
ref: *ci-templates-commit
|
2020-12-03 00:37:16 +08:00
|
|
|
file:
|
2022-10-14 10:19:31 +08:00
|
|
|
- '/templates/alpine.yml'
|
2020-11-25 00:02:13 +08:00
|
|
|
- '/templates/debian.yml'
|
2021-05-12 22:42:37 +08:00
|
|
|
- '/templates/fedora.yml'
|
2021-11-10 05:38:33 +08:00
|
|
|
- local: '.gitlab-ci/image-tags.yml'
|
2021-06-10 18:10:10 +08:00
|
|
|
- local: '.gitlab-ci/lava/lava-gitlab-ci.yml'
|
2022-04-08 19:29:04 +08:00
|
|
|
- local: '.gitlab-ci/container/gitlab-ci.yml'
|
|
|
|
- local: '.gitlab-ci/build/gitlab-ci.yml'
|
|
|
|
- local: '.gitlab-ci/test/gitlab-ci.yml'
|
2023-07-11 23:18:21 +08:00
|
|
|
- local: '.gitlab-ci/farm-rules.yml'
|
2019-10-31 03:39:08 +08:00
|
|
|
- local: '.gitlab-ci/test-source-dep.yml'
|
2023-03-16 18:08:28 +08:00
|
|
|
- local: 'docs/gitlab-ci.yml'
|
2021-02-19 03:12:56 +08:00
|
|
|
- local: 'src/amd/ci/gitlab-ci.yml'
|
2021-07-15 19:11:17 +08:00
|
|
|
- local: 'src/broadcom/ci/gitlab-ci.yml'
|
2020-06-12 19:23:44 +08:00
|
|
|
- local: 'src/etnaviv/ci/gitlab-ci.yml'
|
2021-02-19 03:12:56 +08:00
|
|
|
- local: 'src/freedreno/ci/gitlab-ci.yml'
|
2021-11-24 03:25:41 +08:00
|
|
|
- local: 'src/gallium/drivers/crocus/ci/gitlab-ci.yml'
|
2021-11-21 22:38:20 +08:00
|
|
|
- local: 'src/gallium/drivers/d3d12/ci/gitlab-ci.yml'
|
2021-05-18 06:06:34 +08:00
|
|
|
- local: 'src/gallium/drivers/i915/ci/gitlab-ci.yml'
|
2021-03-02 04:50:51 +08:00
|
|
|
- local: 'src/gallium/drivers/lima/ci/gitlab-ci.yml'
|
2021-02-19 03:12:56 +08:00
|
|
|
- local: 'src/gallium/drivers/llvmpipe/ci/gitlab-ci.yml'
|
2021-12-03 08:14:30 +08:00
|
|
|
- local: 'src/gallium/drivers/nouveau/ci/gitlab-ci.yml'
|
2021-02-19 03:12:56 +08:00
|
|
|
- local: 'src/gallium/drivers/softpipe/ci/gitlab-ci.yml'
|
|
|
|
- local: 'src/gallium/drivers/virgl/ci/gitlab-ci.yml'
|
|
|
|
- local: 'src/gallium/drivers/zink/ci/gitlab-ci.yml'
|
2021-03-19 03:58:04 +08:00
|
|
|
- local: 'src/gallium/frontends/lavapipe/ci/gitlab-ci.yml'
|
2021-12-06 17:01:52 +08:00
|
|
|
- local: 'src/intel/ci/gitlab-ci.yml'
|
2021-11-21 22:41:37 +08:00
|
|
|
- local: 'src/microsoft/ci/gitlab-ci.yml'
|
2021-07-05 15:25:57 +08:00
|
|
|
- local: 'src/panfrost/ci/gitlab-ci.yml'
|
2021-10-25 15:29:07 +08:00
|
|
|
- local: 'src/virtio/ci/gitlab-ci.yml'
|
2019-09-18 22:03:36 +08:00
|
|
|
|
2019-01-20 19:21:45 +08:00
|
|
|
stages:
|
2020-11-19 01:32:05 +08:00
|
|
|
- sanity
|
2020-08-06 23:10:08 +08:00
|
|
|
- container
|
CI: reduce bandwidth for git pull
Over the last 7 days, git pulls represented a total of 1.7 TB.
On those 1.7 TB, we can see:
- ~300 GB for the CI farm on hetzner
- ~730 GB for the CI farm on packet.net
- ~680 GB for the rest of the world
We can not really change the rest of the world*, but we can
certainly reduce the egress costs towards our CI farms.
Right now, the gitlab runners are not doing a good job at
caching the git trees for the various jobs we make, and
we end up with a lot of cache-misses. A typical pipeline
ends up with a good 2.8GB of git pull data. (a compressed
archive of the mesa folder accounts for 280MB)
In this patch, we implemented what was suggested in
https://gitlab.com/gitlab-org/gitlab/-/issues/215591#note_334642576
- we host a brand new MinIO server on packet
- jobs can upload files on 2 locations:
* git-cache/<namespace>/<project>/<branch-name>.tar.gz
* artifacts/<namespace>/<project>/<pipeline-id>/
- the authorization is handled by gitlab with short tokens
valid only for the time of the job is running
- whenever a job runs, the runner are configured to execute
(eval) $CI_PRE_CLONE_SCRIPT
- this variable is set globally to download the current cache
from the MinIO packet server, unpack it and replace the
possibly out of date cache found on the runner
- then git fetch is run by the runner, and only the delta
between the upstream tree and the local tree gets pulled.
We can rebuild the git cache in a schedule job (once a day
seems sufficient), and then we can stop the cache miss
entirely.
First results showed that instead of pulling 280MB of data
in my fork, I got a pull of only 250KB. That should help us.
* arguably, there are other farms in the rest of the world, so
hopefully we can change those too.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5428>
2020-06-11 23:16:28 +08:00
|
|
|
- git-archive
|
2021-06-16 00:23:33 +08:00
|
|
|
- build-x86_64
|
2020-12-02 21:50:38 +08:00
|
|
|
- build-misc
|
2022-08-12 00:11:07 +08:00
|
|
|
- lint
|
2020-12-02 21:50:38 +08:00
|
|
|
- amd
|
2020-12-18 11:40:02 +08:00
|
|
|
- intel
|
2021-12-03 08:14:30 +08:00
|
|
|
- nouveau
|
2020-12-02 21:50:38 +08:00
|
|
|
- arm
|
2021-01-25 19:33:52 +08:00
|
|
|
- broadcom
|
2020-12-02 21:50:38 +08:00
|
|
|
- freedreno
|
2020-06-12 19:23:44 +08:00
|
|
|
- etnaviv
|
2020-12-02 21:57:47 +08:00
|
|
|
- software-renderer
|
2020-12-02 21:50:38 +08:00
|
|
|
- layered-backends
|
2020-12-05 17:15:38 +08:00
|
|
|
- deploy
|
2019-01-20 19:21:45 +08:00
|
|
|
|
2020-07-07 21:02:35 +08:00
|
|
|
|
2020-09-08 18:20:39 +08:00
|
|
|
# YAML anchors for rule conditions
|
|
|
|
# --------------------------------
|
|
|
|
.rules-anchors:
|
|
|
|
rules:
|
2020-09-08 23:47:18 +08:00
|
|
|
# Post-merge pipeline
|
2021-12-16 19:03:18 +08:00
|
|
|
- if: &is-post-merge '$CI_PROJECT_NAMESPACE == "mesa" && $CI_COMMIT_BRANCH'
|
2020-09-08 23:47:18 +08:00
|
|
|
when: on_success
|
2020-09-08 18:36:11 +08:00
|
|
|
# Post-merge pipeline, not for Marge Bot
|
2021-12-16 19:03:18 +08:00
|
|
|
- if: &is-post-merge-not-for-marge '$CI_PROJECT_NAMESPACE == "mesa" && $GITLAB_USER_LOGIN != "marge-bot" && $CI_COMMIT_BRANCH'
|
2020-09-08 18:36:11 +08:00
|
|
|
when: on_success
|
2020-09-08 23:58:32 +08:00
|
|
|
# Pre-merge pipeline
|
2021-12-16 19:09:10 +08:00
|
|
|
- if: &is-pre-merge '$CI_PIPELINE_SOURCE == "merge_request_event"'
|
2020-09-08 23:58:32 +08:00
|
|
|
when: on_success
|
2020-09-08 18:31:08 +08:00
|
|
|
# Pre-merge pipeline for Marge Bot
|
2021-12-16 19:09:10 +08:00
|
|
|
- if: &is-pre-merge-for-marge '$GITLAB_USER_LOGIN == "marge-bot" && $CI_PIPELINE_SOURCE == "merge_request_event"'
|
2020-09-08 18:31:08 +08:00
|
|
|
when: on_success
|
2020-09-08 18:20:39 +08:00
|
|
|
|
|
|
|
|
2022-07-08 02:36:05 +08:00
|
|
|
# When to automatically run the CI for build jobs
|
|
|
|
.build-rules:
|
2019-09-26 15:27:27 +08:00
|
|
|
rules:
|
2020-04-03 18:50:11 +08:00
|
|
|
# If any files affecting the pipeline are changed, build/test jobs run
|
|
|
|
# automatically once all dependency jobs have passed
|
|
|
|
- changes: &all_paths
|
2020-01-13 16:45:57 +08:00
|
|
|
- VERSION
|
2020-05-15 04:51:38 +08:00
|
|
|
- bin/git_sha1_gen.py
|
|
|
|
- bin/install_megadrivers.py
|
|
|
|
- bin/symbols-check.py
|
2020-01-13 16:45:57 +08:00
|
|
|
# GitLab CI
|
|
|
|
- .gitlab-ci.yml
|
|
|
|
- .gitlab-ci/**/*
|
|
|
|
# Meson
|
|
|
|
- meson*
|
|
|
|
- build-support/**/*
|
|
|
|
- subprojects/**/*
|
|
|
|
# Source code
|
|
|
|
- include/**/*
|
|
|
|
- src/**/*
|
2023-06-15 16:49:40 +08:00
|
|
|
- .ci-farms/*
|
2020-01-13 16:45:57 +08:00
|
|
|
when: on_success
|
2022-06-29 06:15:54 +08:00
|
|
|
# Otherwise, build/test jobs won't run because no rule matched.
|
2019-02-22 23:52:08 +08:00
|
|
|
|
2020-01-13 16:45:57 +08:00
|
|
|
|
2019-09-06 23:35:52 +08:00
|
|
|
.ci-deqp-artifacts:
|
2019-06-29 07:35:32 +08:00
|
|
|
artifacts:
|
2020-03-06 19:35:17 +08:00
|
|
|
name: "mesa_${CI_JOB_NAME}"
|
2019-06-29 07:35:32 +08:00
|
|
|
when: always
|
|
|
|
untracked: false
|
|
|
|
paths:
|
|
|
|
# Watch out! Artifacts are relative to the build dir.
|
|
|
|
# https://gitlab.com/gitlab-org/gitlab-ce/commit/8788fb925706cad594adf6917a6c5f6587dd1521
|
|
|
|
- artifacts
|
2021-02-10 00:43:35 +08:00
|
|
|
- _build/meson-logs/*.txt
|
2021-03-04 19:58:56 +08:00
|
|
|
- _build/meson-logs/strace
|
2019-02-22 23:52:08 +08:00
|
|
|
|
2022-04-08 19:29:04 +08:00
|
|
|
.container-rules:
|
2020-04-03 18:50:11 +08:00
|
|
|
rules:
|
2020-06-29 17:33:13 +08:00
|
|
|
# Run pipeline by default in the main project if any CI pipeline
|
|
|
|
# configuration files were changed, to ensure docker images are up to date
|
2020-09-08 23:47:18 +08:00
|
|
|
- if: *is-post-merge
|
2020-06-29 17:33:13 +08:00
|
|
|
changes:
|
|
|
|
- .gitlab-ci.yml
|
|
|
|
- .gitlab-ci/**/*
|
|
|
|
when: on_success
|
2020-04-03 17:46:12 +08:00
|
|
|
# Run pipeline by default if it was triggered by Marge Bot, is for a
|
2020-06-29 17:33:13 +08:00
|
|
|
# merge request, and any files affecting the pipeline were changed
|
2020-09-08 18:31:08 +08:00
|
|
|
- if: *is-pre-merge-for-marge
|
2020-04-03 18:50:11 +08:00
|
|
|
changes:
|
|
|
|
*all_paths
|
|
|
|
when: on_success
|
2020-06-29 17:33:13 +08:00
|
|
|
# Run pipeline by default in the main project if it was not triggered by
|
|
|
|
# Marge Bot, and any files affecting the pipeline were changed
|
2020-09-08 18:36:11 +08:00
|
|
|
- if: *is-post-merge-not-for-marge
|
2020-04-03 18:50:11 +08:00
|
|
|
changes:
|
|
|
|
*all_paths
|
|
|
|
when: on_success
|
2020-06-29 17:33:13 +08:00
|
|
|
# Allow triggering jobs manually in other cases if any files affecting the
|
|
|
|
# pipeline were changed
|
2020-04-03 17:46:12 +08:00
|
|
|
- changes:
|
2020-04-03 18:50:11 +08:00
|
|
|
*all_paths
|
|
|
|
when: manual
|
2022-06-29 06:15:54 +08:00
|
|
|
# Otherwise, container jobs won't run because no rule matched.
|
CI: reduce bandwidth for git pull
Over the last 7 days, git pulls represented a total of 1.7 TB.
On those 1.7 TB, we can see:
- ~300 GB for the CI farm on hetzner
- ~730 GB for the CI farm on packet.net
- ~680 GB for the rest of the world
We can not really change the rest of the world*, but we can
certainly reduce the egress costs towards our CI farms.
Right now, the gitlab runners are not doing a good job at
caching the git trees for the various jobs we make, and
we end up with a lot of cache-misses. A typical pipeline
ends up with a good 2.8GB of git pull data. (a compressed
archive of the mesa folder accounts for 280MB)
In this patch, we implemented what was suggested in
https://gitlab.com/gitlab-org/gitlab/-/issues/215591#note_334642576
- we host a brand new MinIO server on packet
- jobs can upload files on 2 locations:
* git-cache/<namespace>/<project>/<branch-name>.tar.gz
* artifacts/<namespace>/<project>/<pipeline-id>/
- the authorization is handled by gitlab with short tokens
valid only for the time of the job is running
- whenever a job runs, the runner are configured to execute
(eval) $CI_PRE_CLONE_SCRIPT
- this variable is set globally to download the current cache
from the MinIO packet server, unpack it and replace the
possibly out of date cache found on the runner
- then git fetch is run by the runner, and only the delta
between the upstream tree and the local tree gets pulled.
We can rebuild the git cache in a schedule job (once a day
seems sufficient), and then we can stop the cache miss
entirely.
First results showed that instead of pulling 280MB of data
in my fork, I got a pull of only 250KB. That should help us.
* arguably, there are other farms in the rest of the world, so
hopefully we can change those too.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5428>
2020-06-11 23:16:28 +08:00
|
|
|
|
|
|
|
# Git archive
|
|
|
|
|
|
|
|
make git archive:
|
2020-11-19 01:23:29 +08:00
|
|
|
extends:
|
|
|
|
- .fdo.ci-fairy
|
CI: reduce bandwidth for git pull
Over the last 7 days, git pulls represented a total of 1.7 TB.
On those 1.7 TB, we can see:
- ~300 GB for the CI farm on hetzner
- ~730 GB for the CI farm on packet.net
- ~680 GB for the rest of the world
We can not really change the rest of the world*, but we can
certainly reduce the egress costs towards our CI farms.
Right now, the gitlab runners are not doing a good job at
caching the git trees for the various jobs we make, and
we end up with a lot of cache-misses. A typical pipeline
ends up with a good 2.8GB of git pull data. (a compressed
archive of the mesa folder accounts for 280MB)
In this patch, we implemented what was suggested in
https://gitlab.com/gitlab-org/gitlab/-/issues/215591#note_334642576
- we host a brand new MinIO server on packet
- jobs can upload files on 2 locations:
* git-cache/<namespace>/<project>/<branch-name>.tar.gz
* artifacts/<namespace>/<project>/<pipeline-id>/
- the authorization is handled by gitlab with short tokens
valid only for the time of the job is running
- whenever a job runs, the runner are configured to execute
(eval) $CI_PRE_CLONE_SCRIPT
- this variable is set globally to download the current cache
from the MinIO packet server, unpack it and replace the
possibly out of date cache found on the runner
- then git fetch is run by the runner, and only the delta
between the upstream tree and the local tree gets pulled.
We can rebuild the git cache in a schedule job (once a day
seems sufficient), and then we can stop the cache miss
entirely.
First results showed that instead of pulling 280MB of data
in my fork, I got a pull of only 250KB. That should help us.
* arguably, there are other farms in the rest of the world, so
hopefully we can change those too.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5428>
2020-06-11 23:16:28 +08:00
|
|
|
stage: git-archive
|
2020-07-07 21:02:35 +08:00
|
|
|
rules:
|
2022-06-29 01:43:34 +08:00
|
|
|
- !reference [.scheduled_pipeline-rules, rules]
|
CI: reduce bandwidth for git pull
Over the last 7 days, git pulls represented a total of 1.7 TB.
On those 1.7 TB, we can see:
- ~300 GB for the CI farm on hetzner
- ~730 GB for the CI farm on packet.net
- ~680 GB for the rest of the world
We can not really change the rest of the world*, but we can
certainly reduce the egress costs towards our CI farms.
Right now, the gitlab runners are not doing a good job at
caching the git trees for the various jobs we make, and
we end up with a lot of cache-misses. A typical pipeline
ends up with a good 2.8GB of git pull data. (a compressed
archive of the mesa folder accounts for 280MB)
In this patch, we implemented what was suggested in
https://gitlab.com/gitlab-org/gitlab/-/issues/215591#note_334642576
- we host a brand new MinIO server on packet
- jobs can upload files on 2 locations:
* git-cache/<namespace>/<project>/<branch-name>.tar.gz
* artifacts/<namespace>/<project>/<pipeline-id>/
- the authorization is handled by gitlab with short tokens
valid only for the time of the job is running
- whenever a job runs, the runner are configured to execute
(eval) $CI_PRE_CLONE_SCRIPT
- this variable is set globally to download the current cache
from the MinIO packet server, unpack it and replace the
possibly out of date cache found on the runner
- then git fetch is run by the runner, and only the delta
between the upstream tree and the local tree gets pulled.
We can rebuild the git cache in a schedule job (once a day
seems sufficient), and then we can stop the cache miss
entirely.
First results showed that instead of pulling 280MB of data
in my fork, I got a pull of only 250KB. That should help us.
* arguably, there are other farms in the rest of the world, so
hopefully we can change those too.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5428>
2020-06-11 23:16:28 +08:00
|
|
|
# ensure we are running on packet
|
|
|
|
tags:
|
|
|
|
- packet.net
|
|
|
|
script:
|
2020-12-04 21:55:54 +08:00
|
|
|
# Compactify the .git directory
|
|
|
|
- git gc --aggressive
|
2023-06-14 04:40:21 +08:00
|
|
|
# Download & cache the perfetto subproject as well.
|
|
|
|
- rm -rf subprojects/perfetto ; mkdir -p subprojects/perfetto && curl https://android.googlesource.com/platform/external/perfetto/+archive/$(grep 'revision =' subprojects/perfetto.wrap | cut -d ' ' -f3).tar.gz | tar zxf - -C subprojects/perfetto
|
CI: reduce bandwidth for git pull
Over the last 7 days, git pulls represented a total of 1.7 TB.
On those 1.7 TB, we can see:
- ~300 GB for the CI farm on hetzner
- ~730 GB for the CI farm on packet.net
- ~680 GB for the rest of the world
We can not really change the rest of the world*, but we can
certainly reduce the egress costs towards our CI farms.
Right now, the gitlab runners are not doing a good job at
caching the git trees for the various jobs we make, and
we end up with a lot of cache-misses. A typical pipeline
ends up with a good 2.8GB of git pull data. (a compressed
archive of the mesa folder accounts for 280MB)
In this patch, we implemented what was suggested in
https://gitlab.com/gitlab-org/gitlab/-/issues/215591#note_334642576
- we host a brand new MinIO server on packet
- jobs can upload files on 2 locations:
* git-cache/<namespace>/<project>/<branch-name>.tar.gz
* artifacts/<namespace>/<project>/<pipeline-id>/
- the authorization is handled by gitlab with short tokens
valid only for the time of the job is running
- whenever a job runs, the runner are configured to execute
(eval) $CI_PRE_CLONE_SCRIPT
- this variable is set globally to download the current cache
from the MinIO packet server, unpack it and replace the
possibly out of date cache found on the runner
- then git fetch is run by the runner, and only the delta
between the upstream tree and the local tree gets pulled.
We can rebuild the git cache in a schedule job (once a day
seems sufficient), and then we can stop the cache miss
entirely.
First results showed that instead of pulling 280MB of data
in my fork, I got a pull of only 250KB. That should help us.
* arguably, there are other farms in the rest of the world, so
hopefully we can change those too.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5428>
2020-06-11 23:16:28 +08:00
|
|
|
# compress the current folder
|
|
|
|
- tar -cvzf ../$CI_PROJECT_NAME.tar.gz .
|
|
|
|
|
2023-06-08 23:38:22 +08:00
|
|
|
- ci-fairy s3cp --token-file "${CI_JOB_JWT_FILE}" ../$CI_PROJECT_NAME.tar.gz https://$S3_HOST/git-cache/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME/$CI_PROJECT_NAME.tar.gz
|
CI: reduce bandwidth for git pull
Over the last 7 days, git pulls represented a total of 1.7 TB.
On those 1.7 TB, we can see:
- ~300 GB for the CI farm on hetzner
- ~730 GB for the CI farm on packet.net
- ~680 GB for the rest of the world
We can not really change the rest of the world*, but we can
certainly reduce the egress costs towards our CI farms.
Right now, the gitlab runners are not doing a good job at
caching the git trees for the various jobs we make, and
we end up with a lot of cache-misses. A typical pipeline
ends up with a good 2.8GB of git pull data. (a compressed
archive of the mesa folder accounts for 280MB)
In this patch, we implemented what was suggested in
https://gitlab.com/gitlab-org/gitlab/-/issues/215591#note_334642576
- we host a brand new MinIO server on packet
- jobs can upload files on 2 locations:
* git-cache/<namespace>/<project>/<branch-name>.tar.gz
* artifacts/<namespace>/<project>/<pipeline-id>/
- the authorization is handled by gitlab with short tokens
valid only for the time of the job is running
- whenever a job runs, the runner are configured to execute
(eval) $CI_PRE_CLONE_SCRIPT
- this variable is set globally to download the current cache
from the MinIO packet server, unpack it and replace the
possibly out of date cache found on the runner
- then git fetch is run by the runner, and only the delta
between the upstream tree and the local tree gets pulled.
We can rebuild the git cache in a schedule job (once a day
seems sufficient), and then we can stop the cache miss
entirely.
First results showed that instead of pulling 280MB of data
in my fork, I got a pull of only 250KB. That should help us.
* arguably, there are other farms in the rest of the world, so
hopefully we can change those too.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5428>
2020-06-11 23:16:28 +08:00
|
|
|
|
|
|
|
|
2020-08-06 23:37:33 +08:00
|
|
|
# Sanity checks of MR settings and commit logs
|
2020-11-19 01:48:47 +08:00
|
|
|
sanity:
|
2020-11-19 01:23:29 +08:00
|
|
|
extends:
|
|
|
|
- .fdo.ci-fairy
|
2020-08-06 23:37:33 +08:00
|
|
|
stage: sanity
|
|
|
|
rules:
|
2020-12-10 19:48:32 +08:00
|
|
|
- if: *is-pre-merge
|
2020-08-06 23:37:33 +08:00
|
|
|
when: on_success
|
|
|
|
# Other cases default to never
|
2020-12-04 01:58:09 +08:00
|
|
|
variables:
|
|
|
|
GIT_STRATEGY: none
|
2020-08-06 23:37:33 +08:00
|
|
|
script:
|
2020-12-01 21:27:42 +08:00
|
|
|
# ci-fairy check-commits --junit-xml=check-commits.xml
|
2020-11-19 01:48:47 +08:00
|
|
|
- ci-fairy check-merge-request --require-allow-collaboration --junit-xml=check-merge-request.xml
|
|
|
|
artifacts:
|
|
|
|
when: on_failure
|
|
|
|
reports:
|
|
|
|
junit: check-*.xml
|
2023-06-20 21:37:22 +08:00
|
|
|
|
|
|
|
|
|
|
|
# Jobs that need to pass before spending hardware resources on further testing
|
|
|
|
.required-for-hardware-jobs:
|
|
|
|
needs:
|
|
|
|
- job: clang-format
|
|
|
|
optional: true
|
|
|
|
- job: rustfmt
|
|
|
|
optional: true
|