@@ -35,19 +35,28 @@ You can see the status of the cluster with:
35
35
kubectl cluster-info --context kind-capi-test
36
36
` ` `
37
37
38
- # ## Create a tilt-settings.json file
38
+ # ## Create a tilt-settings file
39
+
40
+ Next, create a ` tilt-settings.yaml` file and place it in your local copy of ` cluster-api` . Here is an example:
41
+
42
+ ` ` ` yaml
43
+ default_registry: gcr.io/your-project-name-here
44
+ provider_repos:
45
+ - ../cluster-api-provider-aws
46
+ enable_providers" :
47
+ - aws
48
+ - docker
49
+ - kubeadm-bootstrap
50
+ - kubeadm-control-plane
51
+ ` ` `
39
52
40
- Next, create a ` tilt-settings.json ` file and place it in your local copy of ` cluster-api ` . Here is an example:
53
+ < aside class= " note " >
41
54
42
- ` ` ` json
43
- {
44
- " default_registry" : " gcr.io/your-project-name-here" ,
45
- " provider_repos" : [" ../cluster-api-provider-aws" ],
46
- " enable_providers" : [" aws" , " docker" , " kubeadm-bootstrap" , " kubeadm-control-plane" ]
47
- }
48
- ` ` `
55
+ If you prefer JSON, you can create a ` tilt-settings.json` file instead. YAML will be preferred if both files are present.
56
+
57
+ < /aside>
49
58
50
- # ### tilt-settings.json fields
59
+ # ### tilt-settings fields
51
60
52
61
** allowed_contexts** (Array, default=[]): A list of kubeconfig contexts Tilt is allowed to use. See the Tilt documentation on
53
62
[allow_k8s_contexts](https://docs.tilt.dev/api.html#api.allow_k8s_contexts) for more details.
@@ -56,7 +65,7 @@ Next, create a `tilt-settings.json` file and place it in your local copy of `clu
56
65
documentation](https://docs.tilt.dev/api.html#api.default_registry) for more details.
57
66
58
67
** provider_repos** (Array[]String, default=[]): A list of paths to all the providers you want to use. Each provider must have a
59
- ` tilt-provider.json` file describing how to build the provider.
68
+ ` tilt-provider.yaml ` or ` tilt-provider. json` file describing how to build the provider.
60
69
61
70
** enable_providers** (Array[]String, default=[' docker' ]): A list of the providers to enable. See [available providers](# available-providers)
62
71
for more details.
@@ -94,15 +103,13 @@ Supported settings:
94
103
95
104
Example: Using the configuration below:
96
105
97
- ` ` ` json
98
- " debug" : {
99
- " core" : {
100
- " continue" : false,
101
- " port" : 30000,
102
- " profiler_port" : 40000,
103
- " metrics_port" : 40001
104
- }
105
- },
106
+ ` ` ` yaml
107
+ debug:
108
+ core:
109
+ continue: false
110
+ port: 30000
111
+ profiler_port: 40000
112
+ metrics_port: 40001
106
113
` ` `
107
114
108
115
# #### Wiring up debuggers
@@ -140,10 +147,9 @@ Supported settings:
140
147
141
148
For example, if the yaml contains ` ${AWS_B64ENCODED_CREDENTIALS} ` , you could do the following:
142
149
143
- ` ` ` json
144
- " kustomize_substitutions" : {
145
- " AWS_B64ENCODED_CREDENTIALS" : " your credentials here"
146
- }
150
+ ` ` ` yaml
151
+ kustomize_substitutions:
152
+ AWS_B64ENCODED_CREDENTIALS: " your credentials here"
147
153
` ` `
148
154
149
155
{{# /tab }}
@@ -172,26 +178,24 @@ An Azure Service Principal is needed for populating the controller manifests. Th
172
178
AZURE_CLIENT_ID=$( az ad sp show --id http://$AZURE_SERVICE_PRINCIPAL_NAME --query appId --output tsv)
173
179
` ` `
174
180
175
- Add the output of the following as a section in your ` tilt-settings.json ` :
181
+ Add the output of the following as a section in your ` tilt-settings.yaml ` :
176
182
177
183
` ` ` shell
178
184
cat << EOF
179
- "kustomize_substitutions": {
180
- "AZURE_SUBSCRIPTION_ID_B64": "$( echo " ${AZURE_SUBSCRIPTION_ID} " | tr -d ' \n' | base64 | tr -d ' \n' ) ",
181
- "AZURE_TENANT_ID_B64": "$( echo " ${AZURE_TENANT_ID} " | tr -d ' \n' | base64 | tr -d ' \n' ) ",
182
- "AZURE_CLIENT_SECRET_B64": "$( echo " ${AZURE_CLIENT_SECRET} " | tr -d ' \n' | base64 | tr -d ' \n' ) ",
183
- "AZURE_CLIENT_ID_B64": "$( echo " ${AZURE_CLIENT_ID} " | tr -d ' \n' | base64 | tr -d ' \n' ) "
184
- }
185
+ kustomize_substitutions:
186
+ AZURE_SUBSCRIPTION_ID_B64: "$( echo " ${AZURE_SUBSCRIPTION_ID} " | tr -d ' \n' | base64 | tr -d ' \n' ) "
187
+ AZURE_TENANT_ID_B64: "$( echo " ${AZURE_TENANT_ID} " | tr -d ' \n' | base64 | tr -d ' \n' ) "
188
+ AZURE_CLIENT_SECRET_B64: "$( echo " ${AZURE_CLIENT_SECRET} " | tr -d ' \n' | base64 | tr -d ' \n' ) "
189
+ AZURE_CLIENT_ID_B64: "$( echo " ${AZURE_CLIENT_ID} " | tr -d ' \n' | base64 | tr -d ' \n' ) "
185
190
EOF
186
191
` ` `
187
192
188
193
{{# /tab }}
189
194
{{#tab DigitalOcean}}
190
195
191
- ` ` ` json
192
- "kustomize_substitutions": {
193
- "DO_B64ENCODED_CREDENTIALS": "your credentials here"
194
- }
196
+ ` ` ` yaml
197
+ kustomize_substitutions:
198
+ DO_B64ENCODED_CREDENTIALS: "your credentials here"
195
199
` ` `
196
200
197
201
{{# /tab }}
@@ -202,10 +206,9 @@ You can generate a base64 version of your GCP json credentials file using:
202
206
base64 -i ~/path/to/gcp/credentials.json
203
207
` ` `
204
208
205
- ` ` ` json
206
- "kustomize_substitutions": {
207
- "GCP_B64ENCODED_CREDENTIALS": "your credentials here"
208
- }
209
+ ` ` ` yaml
210
+ kustomize_substitutions:
211
+ GCP_B64ENCODED_CREDENTIALS: "your credentials here"
209
212
` ` `
210
213
211
214
{{# /tab }}
@@ -223,14 +226,11 @@ for this provider. Each item in the array will be passed in to the manager for t
223
226
224
227
Example:
225
228
226
- ` ` ` json
227
- {
228
- " extra_args" : {
229
- " core" : [" --feature-gates=MachinePool=true" ],
230
- " kubeadm-bootstrap" : [" --feature-gates=MachinePool=true" ],
231
- " azure" : [" --feature-gates=MachinePool=true" ]
232
- }
233
- }
229
+ ` ` ` yaml
230
+ extra_args:
231
+ core: [" --feature-gates=MachinePool=true" ]
232
+ kubeadm-bootstrap: [" --feature-gates=MachinePool=true" ]
233
+ azure: [" --feature-gates=MachinePool=true" ]
234
234
` ` `
235
235
236
236
With this config, the respective managers will be invoked with:
@@ -274,23 +274,25 @@ The following providers are currently defined in the Tiltfile:
274
274
* **core**: cluster-api itself (Cluster/Machine/MachineDeployment/MachineSet/KubeadmConfig/KubeadmControlPlane)
275
275
* **docker**: Docker provider (DockerCluster/DockerMachine)
276
276
277
- ### tilt-provider.json
278
-
279
- A provider must supply a `tilt-provider.json` file describing how to build it. Here is an example:
280
-
281
- ```json
282
- {
283
- "name": "aws",
284
- "config": {
285
- "image": "gcr.io/k8s-staging-cluster-api-aws/cluster-api-aws-controller",
286
- "live_reload_deps": [
287
- "main.go", "go.mod", "go.sum", "api", "cmd", "controllers", "pkg"
288
- ]
289
- },
290
- "label": "CAPA"
291
- }
277
+ ### tilt-provider configuration
278
+
279
+ A provider must supply a `tilt-provider.yaml` file describing how to build it. Here is an example:
280
+
281
+ ```yaml
282
+ name: aws
283
+ label: CAPA
284
+ config:
285
+ image: "gcr.io/k8s-staging-cluster-api-aws/cluster-api-aws-controller",
286
+ live_reload_deps: ["main.go", "go.mod", "go.sum", "api", "cmd", "controllers", "pkg"]
292
287
```
293
288
289
+
290
+ <aside class="note">
291
+
292
+ If you prefer JSON, you can create a `tilt-provider.json` file instead. YAML will be preferred if both files are present.
293
+
294
+ </aside>
295
+
294
296
#### config fields
295
297
296
298
**image**: the image for this provider, as referenced in the kustomize files. This must match; otherwise, Tilt won' t
@@ -337,13 +339,13 @@ is immediately before the "real work" happens.
337
339
338
340
At a high level, the Tiltfile performs the following actions:
339
341
340
- 1. Read ` tilt-settings.json `
342
+ 1. Read ` tilt-settings.yaml `
341
343
1. Configure the allowed Kubernetes contexts
342
344
1. Set the default registry
343
345
1. Define the ` providers` map
344
346
1. Include user-defined Tilt files
345
347
1. Deploy cert-manager
346
- 1. Enable providers (` core` + what is listed in ` tilt-settings.json ` )
348
+ 1. Enable providers (` core` + what is listed in ` tilt-settings.yaml ` )
347
349
1. Build the manager binary locally as a ` local_resource`
348
350
1. Invoke ` docker_build` for the provider
349
351
1. Invoke ` kustomize` for the provider' s `config/` directory
0 commit comments