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
This commit adds the --force flag to the alpha update command.
It also adds documentation for the flag.
The --force flag makes it possible to run the alpha update command in CI workflows.
Copy file name to clipboardExpand all lines: docs/book/src/reference/commands/alpha_update.md
+56-4Lines changed: 56 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -60,6 +60,19 @@ kubebuilder alpha update \
60
60
--to-version=v4.6.0 \
61
61
--from-branch=main
62
62
```
63
+
<asideclass="note warning">
64
+
<h1>Projects generated with </h1>
65
+
66
+
Projects generated with **Kubebuilder v4.6.0** or later include the `cliVersion` field in the `PROJECT` file.
67
+
This field is used by `kubebuilder alpha update` to determine the correct CLI
68
+
version for upgrading your project.
69
+
</aside>
70
+
71
+
Force update even with merge conflicts:
72
+
73
+
```sh
74
+
kubebuilder alpha update --force
75
+
```
63
76
64
77
<asideclass="note warning">
65
78
<h1>You might need to upgrade your project first</h1>
@@ -81,17 +94,56 @@ Once updated, you can use `kubebuilder alpha update` for future upgrades.
81
94
|`--from-version`|**Required for projects initialized with versions earlier than v4.6.0.** Kubebuilder version your project was created with. If unset, uses the `PROJECT` file. |
82
95
|`--to-version`| Version to upgrade to. Defaults to the latest version. |
83
96
|`--from-branch`| Git branch that contains your current project code. Defaults to `main`. |
97
+
|`--force`| Force the update even if conflicts occur. Conflicted files will include conflict markers, and a commit will be created automatically. Ideal for automation (e.g., cronjobs, CI). |
84
98
|`-h, --help`| Show help for this command. |
85
99
100
+
## Merge Conflicts with `--force`
101
+
102
+
When you use the `--force` flag with `kubebuilder alpha update`, Git will complete the merge even if there are conflicts. The resulting commit will include conflict markers like:
103
+
```
104
+
<<<<<<< HEAD
105
+
Your changes
106
+
=======
107
+
Incoming changes
108
+
>>>>>>> branch-name
109
+
```
110
+
These conflicts will be committed in the
111
+
`tmp-kb-update-merge` branch.
112
+
86
113
<asideclass="note warning">
87
-
<h1>Projects generated with </h1>
114
+
<h1>You must manually resolve these conflicts before merging into your main branch.</h1>
88
115
89
-
Projects generated with **Kubebuilder v4.6.0** or later include the `cliVersion` field in the `PROJECT` file.
90
-
This field is used by `kubebuilder alpha update` to determine the correct CLI
91
-
version for upgrading your project.
116
+
### Required Steps If Conflicts Are Present
92
117
118
+
If the merge introduces conflicts, follow these steps before committing any final changes:
119
+
1. Resolve Conflicts;
120
+
2. Open the conflicted files and manually edit them to resolve all merge markers;
121
+
3. Run Required Make Targets;
122
+
4. After resolving, run the following command to regenerate, format, vet, and lint the code:
123
+
```
124
+
make manifests generate fmt vet lint-fix
125
+
```
126
+
### Optional (but Recommended)
127
+
128
+
1. Run the full validation suite to ensure your project remains consistent and working:
129
+
```
130
+
make all
131
+
```
132
+
2. Create Pull Request
133
+
After validation, commit your changes and push a pull request from `tmp-kb-update-merge` to your target branch.
93
134
</aside>
94
135
136
+
## When to Use `--force`
137
+
Use `--force` only in scenarios like:
138
+
- Automated environments (e.g., CI pipelines or cron jobs)
139
+
- When you need to create a PR even if conflicts are present
140
+
- When a human will resolve the conflicts later
141
+
`kubebuilder alpha update --force`
142
+
143
+
This ensures the update proceeds without manual blocking but shifts responsibility for conflict resolution to a follow-up manual step.
144
+
145
+
This approach is typically used in automation workflows where conflict markers are later addressed by a human, or where preserving the conflicting changes is acceptable for follow-up processing.
146
+
95
147
## Requirements
96
148
97
149
- A valid [PROJECT][project-config] file at the root of your project
0 commit comments