Skip to content

Commit

Permalink
⚠️ (go/v4-alpha) stabilize go/v4 plugin. Plugin go/v4-alpha replaced …
Browse files Browse the repository at this point in the history
…with go/v4 (kubernetes-sigs#3237)
  • Loading branch information
camilamacedo86 committed Mar 7, 2023
1 parent 56bbc88 commit 014e08c
Show file tree
Hide file tree
Showing 27 changed files with 75 additions and 88 deletions.
11 changes: 1 addition & 10 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -127,16 +127,7 @@ supporting Windows are welcome.

### Apple Silicon

Apple Silicon (`darwin/arm64`) is supported using the `go/v4-alpha` plugin which provides support for this platform.

```bash
kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins=go/v4-alpha
```

**Note**: The `go/v4-alpha` plugin is an unstable version and can have breaking changes in future releases. The previous kustomize
version (`v3.Y.Z`) used in the `go/v3` has no available binaries for this
platform [kubernetes-sigs/kustomize/issues/4612](https://github.com/kubernetes-sigs/kustomize/issues/4612)
Because of this, we cannot support this `darwin/arm64` on the stable scaffold done by default with the Kubebuilder with the `go/v3` plugin.
Apple Silicon (`darwin/arm64`) support begins with the `go/v4` plugin.

## Community Meetings

Expand Down
3 changes: 1 addition & 2 deletions cmd/main.go
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,6 @@ import (
cfgv2 "sigs.k8s.io/kubebuilder/v3/pkg/config/v2"
cfgv3 "sigs.k8s.io/kubebuilder/v3/pkg/config/v3"
"sigs.k8s.io/kubebuilder/v3/pkg/machinery"
"sigs.k8s.io/kubebuilder/v3/pkg/model/stage"
"sigs.k8s.io/kubebuilder/v3/pkg/plugin"
kustomizecommonv1 "sigs.k8s.io/kubebuilder/v3/pkg/plugins/common/kustomize/v1"
kustomizecommonv2alpha "sigs.k8s.io/kubebuilder/v3/pkg/plugins/common/kustomize/v2"
Expand All @@ -46,7 +45,7 @@ func main() {
golangv3.Plugin{},
)
// Bundle plugin which built the golang projects scaffold by Kubebuilder go/v4 with kustomize alpha-v2
gov4Bundle, _ := plugin.NewBundle(golang.DefaultNameQualifier, plugin.Version{Number: 4, Stage: stage.Alpha},
gov4Bundle, _ := plugin.NewBundle(golang.DefaultNameQualifier, plugin.Version{Number: 4},
kustomizecommonv2alpha.Plugin{},
golangv4.Plugin{},
)
Expand Down
4 changes: 2 additions & 2 deletions docs/book/src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@
- [Migration Guide](migration/legacy/migration_guide_v2tov3.md)
- [Migration by updating the files](migration/legacy/manually_migration_guide_v2_v3.md)
- [From v3.0.0 with plugins](./migration/v3-plugins.md)
- [go/v3 vs go/v4-alpha](migration/v3vsv4.md)
- [go/v3 vs go/v4](migration/v3vsv4.md)

- [Migration Guide](migration/migration_guide_gov3_to_gov4.md)
- [Migration by updating the files](migration/manually_migration_guide_gov3_to_gov4.md)
Expand Down Expand Up @@ -117,7 +117,7 @@
- [To scaffold a project](./plugins/to-scaffold-project.md)
- [go/v2 (Deprecated)](./plugins/go-v2-plugin.md)
- [go/v3 (Default init scaffold)](./plugins/go-v3-plugin.md)
- [go/v4-alpha](./plugins/go-v4-plugin.md)
- [go/v4](./plugins/go-v4-plugin.md)
- [To add optional features](./plugins/to-add-optional-features.md)
- [declarative/v1](./plugins/declarative-v1.md)
- [grafana/v1-alpha](./plugins/grafana-v1-alpha.md)
Expand Down
2 changes: 1 addition & 1 deletion docs/book/src/faq.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ After creating a project, usually you will want to extend the Kubernetes APIs an
The domain is for the group suffix, to explicitly show the resource group category.
For example, if set `--domain=example.com`:
```
kubebuilder init --domain example.com --repo xxx --plugins=go/v4-alpha
kubebuilder init --domain example.com --repo xxx --plugins=go/v4
kubebuilder create api --group mygroup --version v1beta1 --kind Mykind
```
Then the result resource group will be `mygroup.example.com`.
Expand Down
6 changes: 2 additions & 4 deletions docs/book/src/migration/legacy/v2vsv3.md
Original file line number Diff line number Diff line change
Expand Up @@ -66,15 +66,13 @@ So you want to upgrade your scaffolding to use the latest and greatest features
<h1> Apple Silicon (M1) </h1>

The current scaffold done by the CLI (`go/v3`) uses [kubernetes-sigs/kustomize][kustomize] v3 which does not provide
a valid binary for Apple Silicon (`darwin/arm64`). Therefore, you can use the `go/v4-alpha` plugin
a valid binary for Apple Silicon (`darwin/arm64`). Therefore, you can use the `go/v4` plugin
instead which provides support for this platform:

```bash
kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins=go/v4-alpha
kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins=go/v4
```

**Note**: The `go/v4-alpha` plugin is an unstable version and can have breaking changes in future releases.
The steps to migrate your project from v2 to v3 using the `alpha` scaffold are the same.
</aside>

- [Migration Guide v2 to V3][migration-guide-v2-to-v3] **(Recommended)**
Expand Down
20 changes: 10 additions & 10 deletions docs/book/src/migration/manually_migration_guide_gov3_to_gov4.md
Original file line number Diff line number Diff line change
@@ -1,18 +1,18 @@
# Migration from go/v3 to go/v4-alpha by updating the files manually
# Migration from go/v3 to go/v4 by updating the files manually

Make sure you understand the [differences between Kubebuilder go/v3 and go/v4-alpha][v3vsv4]
Make sure you understand the [differences between Kubebuilder go/v3 and go/v4][v3vsv4]
before continuing.

Please ensure you have followed the [installation guide][quick-start]
to install the required components.

The following guide describes the manual steps required to upgrade your PROJECT config file to begin using `go/v4-alpha`.
The following guide describes the manual steps required to upgrade your PROJECT config file to begin using `go/v4`.

This way is more complex, susceptible to errors, and success cannot be assured. Also, by following these steps you will not get the improvements and bug fixes in the default generated project files.

Usually it is suggested to do it manually if you have customized your project and deviated too much from the proposed scaffold. Before continuing, ensure that you understand the note about [project customizations][project-customizations]. Note that you might need to spend more effort to do this process manually than to organize your project customizations. The proposed layout will keep your project maintainable and upgradable with less effort in the future.

The recommended upgrade approach is to follow the [Migration Guide go/v3 to go/v4-alpha][migration-guide-gov3-to-gov4] instead.
The recommended upgrade approach is to follow the [Migration Guide go/v3 to go/v4][migration-guide-gov3-to-gov4] instead.

## Migration from project config version "go/v3" to "go/v4"

Expand All @@ -37,7 +37,7 @@ With:

```yaml
layout:
- go.kubebuilder.io/v4-alpha
- go.kubebuilder.io/v4

```

Expand Down Expand Up @@ -152,15 +152,15 @@ The PROJECT tracks the paths of all APIs used in your project. Ensure that they

### Update kustomize manifests with the changes made so far

- Update the manifest under `config/` directory with all changes performed in the default scaffold done with `go/v4-alpha` plugin. (see for example `testdata/project-v4/config/`) to get all changes in the
- Update the manifest under `config/` directory with all changes performed in the default scaffold done with `go/v4` plugin. (see for example `testdata/project-v4/config/`) to get all changes in the
default scaffolds to be applied on your project
- Create `config/samples/kustomization.yaml` with all Custom Resources samples specified into `config/samples`. _(see for example `testdata/project-v4/config/samples/kustomization.yaml`)_

<aside class="warning">
<h1>`config/` directory with changes into the scaffold files</h1>

Note that under the `config/` directory you will find scaffolding changes since using
`go/v4-alpha` you will ensure that you are no longer using Kustomize v3x.
`go/v4` you will ensure that you are no longer using Kustomize v3x.

You can mainly compare the `config/` directory from the samples scaffolded under the `testdata`directory by
checking the differences between the `testdata/project-v3/config/` with `testdata/project-v4/config/` which
Expand Down Expand Up @@ -189,11 +189,11 @@ Update the `go.mod` with the changes which can be found in the samples under `te
### Verification

In the steps above, you updated your project manually with the goal of ensuring that it follows
the changes in the layout introduced with the `go/v4-alpha` plugin that update the scaffolds.
the changes in the layout introduced with the `go/v4` plugin that update the scaffolds.

There is no option to verify that you properly updated the `PROJECT` file of your project.
The best way to ensure that everything is updated correctly, would be to initialize a project using the `go/v4-alpha` plugin,
(ie) using `kubebuilder init --domain tutorial.kubebuilder.io plugins=go/v4-alpha` and generating the same API(s),
The best way to ensure that everything is updated correctly, would be to initialize a project using the `go/v4` plugin,
(ie) using `kubebuilder init --domain tutorial.kubebuilder.io plugins=go/v4` and generating the same API(s),
controller(s), and webhook(s) in order to compare the generated configuration with the manually changed configuration.

Also, after all updates you would run the following commands:
Expand Down
18 changes: 9 additions & 9 deletions docs/book/src/migration/migration_guide_gov3_to_gov4.md
Original file line number Diff line number Diff line change
@@ -1,19 +1,19 @@
# Migration from go/v3 to go/v4-alpha
# Migration from go/v3 to go/v4

Make sure you understand the [differences between Kubebuilder go/v3 and go/v4-alpha][v3vsv4]
Make sure you understand the [differences between Kubebuilder go/v3 and go/v4][v3vsv4]
before continuing.

Please ensure you have followed the [installation guide][quick-start]
to install the required components.

The recommended way to migrate a go/v3 project is to create a new go/v4-alpha project and
The recommended way to migrate a `go/v3` project is to create a new `go/v4` project and
copy over the API and the reconciliation code. The conversion will end up with a
project that looks like a native go/v4-alpha project layout (latest version).
project that looks like a native go/v4 project layout (latest version).

However, in some cases, it's possible to do an in-place upgrade (i.e. reuse the go/v3 project layout, upgrading
the PROJECT file, and scaffolds manually). For further information see [Migration from go/v3 to go/v4-alpha by updating the files manually][manually-upgrade]
the PROJECT file, and scaffolds manually). For further information see [Migration from go/v3 to go/v4 by updating the files manually][manually-upgrade]

## Initialize a go/v4-alpha Project
## Initialize a go/v4 Project

<aside class="note">
<h1>Project name</h1>
Expand All @@ -30,7 +30,7 @@ $ mkdir migration-project-name
$ cd migration-project-name
```

Now, we need to initialize a go/v4-alpha project. Before we do that, we'll need
Now, we need to initialize a go/v4 project. Before we do that, we'll need
to initialize a new go module if we're not on the `GOPATH`. While technically this is
not needed inside `GOPATH`, it is still recommended.

Expand All @@ -50,7 +50,7 @@ module tutorial.kubebuilder.io/migration-project
Now, we can finish initializing the project with kubebuilder.

```bash
kubebuilder init --domain tutorial.kubebuilder.io --plugins=go/v4-alpha
kubebuilder init --domain tutorial.kubebuilder.io --plugins=go/v4
```

<aside class="note">
Expand Down Expand Up @@ -119,7 +119,7 @@ Now, let's copy the webhook definition from `api/v1/<kind>_webhook.go` from our
If there are any manual updates in `main.go` in v3, we need to port the changes to the new `main.go`. We’ll also need to ensure all of needed controller-runtime `schemes` have been registered.

If there are additional manifests added under config directory, port them as well. Please, be aware that
the new version go/v4-alpha uses Kustomize v5x and no longer Kustomize v4. Therefore, if added customized
the new version go/v4 uses Kustomize v5x and no longer Kustomize v4. Therefore, if added customized
implementations in the config you need to ensure that them can work with Kustomize v5 and/if not
update/upgrade any breaking change that you might face.

Expand Down
4 changes: 2 additions & 2 deletions docs/book/src/migration/multi-group.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,9 +21,9 @@ to modify the default project structure to support it.
Let's migrate the [CronJob example][cronjob-tutorial].

<aside class="note warning">
<h1>Using go/v4-alpha</h1>
<h1>Using go/v4</h1>

If you create your project using go/v4-alpha plugin (you can verify it by looking at the PROJECT file )
If you create your project using go/v4 plugin (you can verify it by looking at the PROJECT file )
then, all steps are the same but you need to keep in mind that the api and controllers directory
path is now under the `pkg` directory instead. So, you need ensure that you update the
paths accordingly.
Expand Down
22 changes: 11 additions & 11 deletions docs/book/src/migration/v3vsv4.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# go/v3 vs go/v4-alpha
# go/v3 vs go/v4

This document covers all breaking changes when migrating from projects built using the plugin go/v3 (default for any scaffold done since `28 Apr 2021`) to the next alpha version of the Golang plugin `go/v4-alpha`.
This document covers all breaking changes when migrating from projects built using the plugin go/v3 (default for any scaffold done since `28 Apr 2021`) to the next alpha version of the Golang plugin `go/v4`.

The details of all changes (breaking or otherwise) can be found in:

Expand All @@ -11,7 +11,7 @@ The details of all changes (breaking or otherwise) can be found in:

## Common changes

- `go/v4-alpha` projects use Kustomize v4x (instead of v3x)
- `go/v4` projects use Kustomize v5x (instead of v3x)
- note that some manifests under `config/` directory have been changed in order to no longer use the deprecated Kustomize features
such as env vars.
- A `kustomization.yaml` is scaffolded under `config/samples`. This helps simply and flexibly generate sample manifests: `kustomize build config/samples`.
Expand All @@ -24,13 +24,13 @@ The details of all changes (breaking or otherwise) can be found in:
by moving the api(s) under a new directory called `api`, controller(s) under a new directory called `internal` and the `main.go` under a new directory named `cmd`

<aside class="note">
<H1> TL;DR of the New `go/v4-alpha` Plugin </H1>
<H1> TL;DR of the New `go/v4` Plugin </H1>

Further details can be found in the [go/v4-alpha plugin section][go/v4-doc]
Further details can be found in the [go/v4 plugin section][go/v4-doc]

</aside>

## TL;DR of the New `go/v4-alpha` Plugin
## TL;DR of the New `go/v4` Plugin

**_More details on this can be found at [here][kb-releases], but for the highlights, check below_**

Expand All @@ -49,7 +49,7 @@ For example, you should refrain from moving the scaffolded files, doing so will

</aside>

## Migrating to Kubebuilder go/v4-alpha
## Migrating to Kubebuilder go/v4

If you want to upgrade your scaffolding to use the latest and greatest features then, follow the guide
which will cover the steps in the most straightforward way to allow you to upgrade your project to get all
Expand All @@ -59,14 +59,14 @@ latest changes and improvements.
<h1> Apple Silicon (M1) </h1>

The current scaffold done by the CLI (`go/v3`) uses [kubernetes-sigs/kustomize][kustomize] v3 which does not provide
a valid binary for Apple Silicon (`darwin/arm64`). Therefore, you can use the `go/v4-alpha` plugin
a valid binary for Apple Silicon (`darwin/arm64`). Therefore, you can use the `go/v4` plugin
instead which provides support for this platform:

```bash
kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins=go/v4-alpha
kubebuilder init --domain my.domain --repo my.domain/guestbook --plugins=go/v4
```

**Note**: The `go/v4-alpha` plugin is an unstable version and can have breaking changes in future releases.
**Note**: The `go/v4` plugin is an unstable version and can have breaking changes in future releases.

</aside>

Expand All @@ -78,7 +78,7 @@ If you want to use the latest version of Kubebuilder CLI without changing your s

This way is more complex, susceptible to errors, and success cannot be assured. Also, by following these steps you will not get the improvements and bug fixes in the default generated project files.

- [Migrating to go/v4-alpha by updating the files manually][manually-upgrade]
- [Migrating to go/v4 by updating the files manually][manually-upgrade]

[plugins-phase1-design-doc]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/extensible-cli-and-scaffolding-plugins-phase-1.md
[plugins-phase1-design-doc-1.5]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/extensible-cli-and-scaffolding-plugins-phase-1-5.md
Expand Down
4 changes: 2 additions & 2 deletions docs/book/src/plugins/creating-plugins.md
Original file line number Diff line number Diff line change
Expand Up @@ -147,8 +147,8 @@ You might want for example to overwrite a scaffold done by using the option:
f.IfExistsAction = machinery.OverwriteFile
```

Let's imagine that you would like to have a helper plugin that would be called in a chain with `go/v4-alpha` to add customizations on top.
Therefore after we generate the code calling the subcommand to `init` from `go/v4-alpha` we would like to overwrite the Makefile to change this scaffold via our plugin.
Let's imagine that you would like to have a helper plugin that would be called in a chain with `go/v4` to add customizations on top.
Therefore after we generate the code calling the subcommand to `init` from `go/v4` we would like to overwrite the Makefile to change this scaffold via our plugin.
In this way, we would implement the Bollerplate for our Makefile and then use this option to ensure that it would be overwritten.

See [example of deploy-image][example-of-deploy-image-1].
Expand Down
14 changes: 7 additions & 7 deletions docs/book/src/plugins/go-v4-plugin.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# go/v4-alpha (go.kubebuilder.io/v4-alpha)
# go/v4 (go.kubebuilder.io/v4)

Kubebuilder will scaffold using the `go/v4-alpha` plugin only if specified when initializing the project.
This plugin is a composition of the plugins ` kustomize.common.kubebuilder.io/v2-alpha` and `base.go.kubebuilder.io/v4-alpha`.
Kubebuilder will scaffold using the `go/v4` plugin only if specified when initializing the project.
This plugin is a composition of the plugins ` kustomize.common.kubebuilder.io/v2-alpha` and `base.go.kubebuilder.io/v4`.
It scaffolds a project template that helps in constructing sets of [controllers][controller-runtime].

It scaffolds boilerplate code to create and design controllers.
Expand Down Expand Up @@ -31,17 +31,17 @@ the "api(s)" are scaffold under the `api` directory, "controller(s)" under `inte

<h1>Migration from `go/v3`</h1>

If you have a project created with `go/v3` (default layout since `28 Apr 2021` and Kubebuilder release version `3.0.0`) to `go/v4-alpha` then,
see the migration guide [Migration from go/v3 to go/v4-alpha](./../migration/migration_guide_gov3_to_gov4.md)
If you have a project created with `go/v3` (default layout since `28 Apr 2021` and Kubebuilder release version `3.0.0`) to `go/v4` then,
see the migration guide [Migration from go/v3 to go/v4](./../migration/migration_guide_gov3_to_gov4.md)

</aside>

## How to use it ?

To create a new project with the `go/v4-alpha` plugin the following command can be used:
To create a new project with the `go/v4` plugin the following command can be used:

```sh
kubebuilder init --domain tutorial.kubebuilder.io --repo tutorial.kubebuilder.io/project --plugins=go/v4-alpha
kubebuilder init --domain tutorial.kubebuilder.io --repo tutorial.kubebuilder.io/project --plugins=go/v4
```

## Subcommands supported by the plugin
Expand Down
Loading

0 comments on commit 014e08c

Please sign in to comment.