1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
variables:
# https://docs.gitlab.com/runner/configuration/feature-flags.html
FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR: true # fix permissions
FF_SCRIPT_SECTIONS: true # tidier logs?
FF_TIMESTAMPS: true # timestamps on log lines
FF_USE_FASTZIP: true # faster archive creation
# CI configuration (deliberately not converted to inputs; see #1997)
CH_PIPELINE_MODE:
description: "Pipeline mode to use."
value: ci
options:
- ci
- daily
# our environment variables
CH_IMAGE_STORAGE: /var/tmp/stg
CH_TEST_IMGDIR: /var/tmp/img
CH_TEST_TARDIR: /var/tmp/pck
LC_ALL: C # boring and consistent
workflow:
# Big name doesn’t seem meaningful?
#name: "$CI_PIPELINE_SOURCE/$CI_COMMIT_BRANCH$CI_MERGE_REQUEST_IID/$CH_PIPELINE_MODE $CI_COMMIT_SHORT_SHA $CI_COMMIT_TITLE"
rules:
# Exclude branch pipelines for MRs.
- if: $CI_PIPELINE_SOURCE == "push" && $CI_OPEN_MERGE_REQUESTS
when: never
- when: always
include:
local: test/gitlab.com/base.yml
ci-images:
# Build the images used for the rest of the pipeline, if needed [1]. Notes:
#
# 1. This uses a second “service” container for the Docker daemon, which
# seems unnecessary to me, but I couldn’t figure out how to start the
# Docker daemon in a tidy way otherwise. It’s also how the examples in
# the docs do it.
#
# 2. We enable TLS, which also seems unnecessary but the docs encourage it
# and the Docker daemon yells if you don’t.
#
# 3. Build sequentially so images can chain, but WARNING: Dockerfiles can
# only be based on an image in this directory if it is lexially prior.
#
# [1]: https://docs.gitlab.com/ee/ci/docker/using_docker_build.html
extends: .base
image: docker:27-cli # client tools only?
rules:
- when: on_success
parallel:
matrix:
- ci_arch: [amd64]
variables:
# DOCKER_HOST set automatically
DOCKER_TLS_CERTDIR: "/certs"
services:
- name: docker:27-dind
alias: daemon
script:
- echo "$CI_REGISTRY_PASSWORD"
| docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin
- build-images $CI_COMMIT_REF_NAME test/gitlab.com/*.df
review-nag:
extends: .base
tags: [saas-linux-small-amd64]
needs: [ci-images]
variables:
ci_distro: debian
rules:
- if: $CH_PIPELINE_MODE == "daily"
when: on_success
script: |
test/gitlab.com/reviews-email --to $CH_DLQ_TO \
--from $CH_DLQ_FROM \
--host $CH_DLQ_HOST \
--port $CH_DLQ_PORT \
--user $CH_DLQ_USER \
--pass $CH_DLQ_PASS
# This computes lines of code for easy reference, because to do it locally
# requires completely de-configuring, which is a hassle and easily forgotten.
loc:
extends: [.base, .rules-standard]
tags: [saas-linux-small-amd64]
needs: [ci-images]
variables:
ci_distro: debian
script:
- misc/loc
# The rest of CI happens in a child pipeline. Because GitLab CI (1) cannot
# specify “needs” on specific jobs within a matrix, and (2) jobs get artifacts
# from *all* jobs in an upstream matrix, we do the matrix expansion
# manually [1]. My hope is that in the future, GitLab will grow the necessary features and we can delete this.
#
# [1]: https://gitlab.com/gitlab-org/gitlab/-/issues/423553
child-expand:
extends: [.base, .rules-quick]
tags: [saas-linux-small-amd64]
needs: [ci-images]
variables:
ci_distro: debian
artifacts:
paths: ["test/gitlab.com/matrix.yml"]
script: |
cd test/gitlab.com
./expand-matrices < matrix.yml.in > matrix.yml
child-run:
extends: [.rules-quick]
needs: [child-expand]
trigger:
include:
- artifact: test/gitlab.com/matrix.yml
job: child-expand
strategy: depend # why not mirror? I’m confused
forward:
pipeline_variables: true
yaml_variables: true
website:
# Re-deploy the website by triggering a pipeline in the website project,
# i.e. https://gitlab.com/charliecloud/website. It runs for any of
# (a) manually triggered pipelines, (b) pushes to main, and (c) MR pushes if
# the MR is labelled “ci-downstream”. Triggering the downstream pipelines
# when they shouldn’t be should have no effect other than wasting resources.
needs: [child-run]
rules:
- if: $CH_PIPELINE_MODE == "ci"
&& ( $CI_PIPELINE_SOURCE == "web"
|| $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
|| $CI_MERGE_REQUEST_LABELS =~ /ci-downstream/ )
when: always
trigger:
project: charliecloud/website
|
