-
Notifications
You must be signed in to change notification settings - Fork 1.6k
✨ (alpha update) initial code for the alpha update
command
#4871
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ (alpha update) initial code for the alpha update
command
#4871
Conversation
Hi @vitorfloriano. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/ok-to-test
@vitorfloriano great work 🎉 — very solid progress! Amazing ⭐ 🚀
I’ve added some comments to the PR. Once those are addressed, the next step would be to implement a happy path test to validate the new command — similar to the structure used in:
👉 https://github.com/kubernetes-sigs/kubebuilder/tree/master/test/e2e/alphagenerate
How can we do the test:
Following some steps and references to help you out:
-
Create a project using Kubebuilder Latest release
Ref:generate_test.go#L231-L239
-
Init a new API within the project
Ref:generate_test.go#L208-L229
-
Use plugin utils to modify the controller
Instead of changing the whole project, we can inject custom reconcile logic into the controller file. Example from this PR commit:
camilamacedo86/wordpress-operator@380c8c9 -
Call the new
alpha update
command -
Verify the results:
- The project should reflect the merged scaffold based on the latest version.
Ref:generate_test.go#L437-L440
(no errors were faced)
- The project should reflect the merged scaffold based on the latest version.
Please let me know if you’d like to pair or discuss any of this further. Happy to help 😄
ffe03ae
to
565f736
Compare
74151d3
to
4ac73de
Compare
70a8582
to
139fac2
Compare
alpha update
command
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @varshaprasad96 and @Kavinjsir
I’m approving this one to allow us to move forward incrementally.
That said, please feel free to take your time and add your reviews— we can address any feedback in a follow-up.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: camilamacedo86, vitorfloriano The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This commit introduces the `kubebuilder alpha update` command, which enables users to upgrade their Kubebuilder projects via a 3-way Git merge strategy. The update flow: - Creates an 'ancestor' branch based on the original scaffold version - Extracts the user's current project state into a 'current' branch - Generates a fresh scaffold using the target version in the 'upgrade' branch - Merges changes into a 'merge' branch, preserving user code and applying updates This mechanism allows users to safely adopt new scaffolding and maintain their custom logic with minimal manual effort.
139fac2
to
0844168
Compare
New changes are detected. LGTM label has been removed. |
/test pull-kubebuilder-e2e-k8s-1-32-0 |
/test pull-kubebuilder-e2e-k8s-1-33-0 |
The
kubebuilder alpha update
command performs a three-way Git merge to upgrade a project to a newer Kubebuilder version while preserving user-defined code. The process is fully automated and follows these main steps:1. Ancestor Branch (baseline scaffold)
2. Original Branch (user’s current code)
3. Upgrade Branch (target scaffold)
4. Merge Branch (final result)
This command provides a reliable and repeatable way to upgrade project scaffolding while preserving user customizations. Flags like --from-version, --to-version, and --from-branch offer full control over the versions and branches involved in the update.
Example: