-
Notifications
You must be signed in to change notification settings - Fork 9
/
.gitlab-ci-magnum.yml.sample
157 lines (151 loc) · 5.82 KB
/
.gitlab-ci-magnum.yml.sample
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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
---
default:
image: ubuntu:jammy
variables:
# Because we are installing git-crypt as part of the job, we cannot reuse old
# checkouts where git-crypt is already initialised as this results in an error
GIT_STRATEGY: clone
# Use the pipeline credentials for Terraform
# This assumes that we are using GitLab-managed Terraform state (recommended when available)
TF_HTTP_USERNAME: gitlab-ci-token
TF_HTTP_PASSWORD: $CI_JOB_TOKEN
stages:
# This stage owns the scheduled job that checks for upstream changes
- scheduled
# This stage owns the deploy job for the staging environment
- staging
# This stage owns the deploy job for the production environment
- production
#####
# This job checks to see if there is a new release that needs to be merged
#
# If there is, it will create a new branch containing the changes and a corresponding merge request
#
# It runs as a scheduled job, for which a suitable schedule must be defined, e.g. daily or weekly
#
# This job writes back to the repository and to the merge requests API
# To do this, it needs more power than is granted to the CI token
# So CI variables must be set that contain an access token and the corresponding username
# This can be a Project Access Token (paid feature, recommended if available) or a Personal Access Token (not ideal)
#####
check_for_release:
stage: scheduled
rules:
- if: $CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_BRANCH == "main"
variables:
GIT_STRATEGY: none
before_script:
- apt update -y
- apt install -y curl git jq
script:
# Configure git to use the available credentials
- git config --global credential.helper store
# Do our own clone to make sure we don't get unrelated history errors from detached heads
- git clone https://${GITLAB_PAT_USERNAME}:${GITLAB_PAT_TOKEN}@${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git ${CI_PROJECT_NAME}
- cd ${CI_PROJECT_NAME}
# Tell git who we are for commits
- git config user.email "${CI_PROJECT_PATH_SLUG}-ci@${CI_SERVER_HOST}"
- git config user.name "${CI_PROJECT_NAME} CI"
# Create the merge branch
- ./bin/create-merge-branch
# Create a merge request for the branch
- |
if [ -f ".mergeenv" ]; then
source ".mergeenv"
BODY="{
\"id\": ${CI_PROJECT_ID},
\"title\": \"Upgrade config to upstream version ${RELEASE_TAG}\",
\"source_branch\": \"${BRANCH_NAME}\",
\"target_branch\": \"main\",
\"remove_source_branch\": true,
\"assignee_id\": \"${GITLAB_USER_ID}\"
}"
curl -kfsSL -X POST \
"${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests" \
--header "Authorization: Bearer ${GITLAB_PAT_TOKEN}" \
--header "Content-Type: application/json" \
--data "${BODY}"
fi
#####
# This job deploys a staging/test version of the Magnum CAPI management cluster
#
# It runs automatically for every commit to main that changes one of the files
# that affects the environment.
#
# NOTE: If the target site doesn't have a separate staging cloud with it's own Magnum
# deployment then it may still be worth including a management cluster staging env in
# this config repo which is a stripped down (1 master, 1 worker) version of the prod
# env. Although this will not allow for testing the interaction between Magnum and the
# CAPI management cluster, it will at least validate the deployment config before a
# production rollout is performed.
#####
deploy_staging:
stage: staging
rules:
# Prevent the job from running on any branch that is not main
- if: $CI_COMMIT_BRANCH != "main"
when: never
# Allow deployments to be manually triggered on main even when there are no changed files
- if: $CI_PIPELINE_SOURCE == "web"
# Run for commits to main that change particular files
- if: $CI_PIPELINE_SOURCE == "push"
changes:
# Files that affect the staging environment
- env
- env.secret
- requirements.yml
- environments/base/**/*
- environments/ha/**/*
- environments/capi-mgmt/**/*
# TODO: Change these to actual site environment names
- environments/site-base/**/*
- environments/site-staging/**/*
environment:
# TODO: Change this to site staging environment name
name: site-staging
variables:
ANSIBLE_FORCE_COLOR: "true"
before_script:
- source ./bin/ci-setup
script:
- ansible-playbook azimuth_cloud.azimuth_ops.provision_capi_mgmt
#####
# This job deploys the Magnum CAPI management cluster to the production environment
#
# It runs for every commit to main that changes one of the files that affects
# the environment, but only if the staging deployment succeeded
#
# It also includes a manual gate that can be used as a confirmation that the
# relevant testing has taken place on staging
#####
deploy_production:
stage: production
rules:
# Prevent the job from running on any branch that is not main
- if: $CI_COMMIT_BRANCH != "main"
when: never
# Allow deployments to be manually triggered on main even when there are no changed files
- if: $CI_PIPELINE_SOURCE == "web"
when: manual
# Run for commits to main that change particular files
- if: $CI_PIPELINE_SOURCE == "push"
changes:
- env
- env.secret
- requirements.yml
- environments/base/**/*
- environments/ha/**/*
- environments/capi-mgmt/**/*
# TODO: Change these to actual site environment names
- environments/site-base/**/*
- environments/site-staging/**/*
when: manual
environment:
# TODO: Change this to site prod environment name
name: site-prod
variables:
ANSIBLE_FORCE_COLOR: "true"
before_script:
- source ./bin/ci-setup
script:
- ansible-playbook azimuth_cloud.azimuth_ops.provision_capi_mgmt