You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/spec/v1alpha2/imageupdateautomations.md
+182-7Lines changed: 182 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,6 +9,8 @@ the automation process checks the image policy named, and updates the field valu
9
9
image selected by the policy. The marker format is shown in the [image automation
10
10
guide][image-auto-guide].
11
11
12
+
To see what has changed between the API version v1alpha1 and this version v1alpha2, read [the section on migration](#migrating-from-v1alpha1) at the bottom.
13
+
12
14
## Specification
13
15
14
16
```go
@@ -68,8 +70,8 @@ type SourceReference struct {
68
70
69
71
To be able to commit changes back, the referenced `GitRepository` object must refer to credentials
70
72
with write access; e.g., if using a GitHub deploy key, "Allow write access" should be checked when
71
-
creating it. Only the `url`, `secretRef` and `gitImplementation` (see just below) fields of the
72
-
`GitRepository` are used.
73
+
creating it. Only the `url`, `ref`, `secretRef` and `gitImplementation` (see just below) fields of
74
+
the `GitRepository` are used.
73
75
74
76
The `gitImplementation` field in the referenced `GitRepository` object controls which git library is
75
77
used. This will matter if you run on Azure, and possibly otherwise -- see [the source controller
@@ -192,11 +194,12 @@ want to put tokens in to control how CI reacts to commits made by automation. Fo
192
194
193
195
```yaml
194
196
spec:
195
-
commit:
196
-
messageTemplate: |
197
-
Automated image update by Flux
198
-
199
-
[ci skip]
197
+
git:
198
+
commit:
199
+
messageTemplate: |
200
+
Automated image update by Flux
201
+
202
+
[ci skip]
200
203
```
201
204
202
205
The following section describes what data is available to use in the template.
@@ -417,6 +420,178 @@ There is one condition maintained by the controller, which is the usual `ReadyCo
417
420
condition. This will be recorded as `True` when automation has run without errors, whether or not it
418
421
resulted in a commit.
419
422
423
+
## Migrating from `v1alpha1`
424
+
425
+
For the most part, `v1alpha2` rearranges the API types to provide for future extension. Here are the
426
+
differences, and where each `v1alpha1` field goes. A full example appears after the table.
427
+
428
+
### Moves and changes
429
+
430
+
| v1alpha1 field | change in v1alpha2 |
431
+
+----------------+--------------------+
432
+
| .spec.checkout | moved to `.spec.git.checkout`, and optional |
433
+
||`gitRepositoryRef` is now `.spec.sourceRef`|
434
+
||`branch` is now `ref`, and optional |
435
+
| .spec.commit | moved to `.spec.git.commit`|
436
+
||`authorName` and `authorEmail` now `author.name` and `author.email`|
437
+
| .spec.push | moved to `.spec.git.push`|
438
+
439
+
### Example of rewriting a v1alpha1 object to v1alpha2
440
+
441
+
This example shows the steps to rewrite a v1alpha1 ImageUpdateAutomation YAML to be a v1alpha2 YAML.
0 commit comments