Skip to content

Commit ad5f0b8

Browse files
authored
Merge pull request #2101 from kubernetes-sigs/master
🌱 Update release-3 for v3.0.0-beta.1
2 parents 6eff28d + b789900 commit ad5f0b8

File tree

373 files changed

+12858
-6753
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

373 files changed

+12858
-6753
lines changed

.github/workflows/ci.yml

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,7 @@ jobs:
1919
- name: Execute golangci-lint
2020
uses: golangci/golangci-lint-action@v2
2121
with:
22-
version: v1.29 # Always uses the latest patch version.
22+
version: v1.37 # Always uses the latest patch version.
2323
only-new-issues: true # Show only new issues if it's a pull request
2424

2525
testdata:
@@ -34,7 +34,7 @@ jobs:
3434
- name: Setup Go
3535
uses: actions/setup-go@v2
3636
with:
37-
go-version: '^1.15'
37+
go-version: '1.15'
3838
# This step is needed as the following one tries to remove
3939
# kustomize for each test but has no permission to do so
4040
- name: Remove pre-installed kustomize
@@ -57,7 +57,7 @@ jobs:
5757
- name: Setup Go
5858
uses: actions/setup-go@v2
5959
with:
60-
go-version: '^1.15'
60+
go-version: '1.15'
6161
# This step is needed as the following one tries to remove
6262
# kustomize for each test but has no permission to do so
6363
- name: Remove pre-installed kustomize
@@ -80,7 +80,7 @@ jobs:
8080
- name: Setup Go
8181
uses: actions/setup-go@v2
8282
with:
83-
go-version: '^1.15'
83+
go-version: '1.15'
8484
- name: Generate the coverage output
8585
run: make test-coverage
8686
- name: Send the coverage output

Makefile

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -82,7 +82,7 @@ GOLANGCI_LINT = $(shell pwd)/bin/golangci-lint
8282
golangci-lint:
8383
@[ -f $(GOLANGCI_LINT) ] || { \
8484
set -e ;\
85-
curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(shell dirname $(GOLANGCI_LINT)) v1.29.0 ;\
85+
curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(shell dirname $(GOLANGCI_LINT)) v1.37.1 ;\
8686
}
8787

8888
##@ Tests
@@ -97,7 +97,7 @@ test-unit: ## Run the unit tests
9797
.PHONY: test-coverage
9898
test-coverage: ## Run unit tests creating the output to report coverage
9999
- rm -rf *.out # Remove all coverage files if exists
100-
go test -race -failfast -tags=integration -coverprofile=coverage-all.out -coverpkg="./pkg/cli/...,./pkg/config/...,./pkg/internal/...,./pkg/model/...,./pkg/plugin/...,./pkg/plugins/golang,./pkg/plugins/internal/..." ./pkg/...
100+
go test -race -failfast -tags=integration -coverprofile=coverage-all.out -coverpkg="./pkg/cli/...,./pkg/config/...,./pkg/internal/...,./pkg/machinery/...,./pkg/model/...,./pkg/plugin/...,./pkg/plugins/golang" ./pkg/...
101101

102102
.PHONY: test-integration
103103
test-integration: ## Run the integration tests

README.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,6 @@
11
[![Build Status](https://travis-ci.org/kubernetes-sigs/kubebuilder.svg?branch=master)](https://travis-ci.org/kubernetes-sigs/kubebuilder "Travis")
22
[![Go Report Card](https://goreportcard.com/badge/sigs.k8s.io/kubebuilder)](https://goreportcard.com/report/sigs.k8s.io/kubebuilder)
3+
[![Coverage Status](https://coveralls.io/repos/github/kubernetes-sigs/kubebuilder/badge.svg?branch=master)](https://coveralls.io/github/kubernetes-sigs/kubebuilder?branch=master)
34

45
## Kubebuilder
56

RELEASE.md

Lines changed: 10 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2,19 +2,25 @@
22

33
The Kubebuilder Project is released on an as-needed basis. The process is as follows:
44

5-
1. An issue is proposing a new release with a changelog since the last release
5+
1. An issue is proposing a new release with a changelog since the last release. You will need to use the [kubebuilder-release-tools][kubebuilder-release-tools] to generate the notes. See [here][release-notes-generation]
66
1. All [OWNERS](OWNERS) must LGTM this release
7-
1. An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION`
8-
1. A PR needs to be created to merge `master` branch into `book-v2` to pick up the new docs.
7+
1. An OWNER runs `git tag -s $VERSION` and pushes the tag with `git push $VERSION`. Note that after the OWNER push the tag the CI will automatically add the release notes and the assets.
8+
1. A PR needs to be created to merge `release-X` branch into `book-vX` to pick up the new docs.
99
1. The release issue is closed
1010
1. An announcement email is sent to `[email protected]` with the subject `[ANNOUNCE] kubebuilder $VERSION is released`
1111

12-
Note: This process does not apply to EAP or alpha (pre-)releases which may be cut at any time for development
12+
**Notes:** This process does not apply to EAP or alpha (pre-)releases which may be cut at any time for development
1313
and testing.
1414

15+
For further information about versioning and update the Kubebuilder binaries check the [versioning][release-process] doc.
16+
1517
## HEAD releases
1618

1719
The binaries releases for HEAD are available here:
1820

1921
- [kubebuilder-release-master-head-darwin-amd64.tar.gz](https://storage.googleapis.com/kubebuilder-release/kubebuilder-release-master-head-darwin-amd64.tar.gz)
2022
- [kubebuilder-release-master-head-linux-amd64.tar.gz](https://storage.googleapis.com/kubebuilder-release/kubebuilder-release-master-head-linux-amd64.tar.gz)
23+
24+
[kubebuilder-release-tools]: https://github.com/kubernetes-sigs/kubebuilder-release-tools
25+
[release-notes-generation]: https://github.com/kubernetes-sigs/kubebuilder-release-tools/blob/master/README.md#release-notes-generation
26+
[release-process]: https://github.com/kubernetes-sigs/kubebuilder/blob/master/VERSIONING.md#releasing

cmd/main.go

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,7 @@ import (
2222
"sigs.k8s.io/kubebuilder/v3/pkg/cli"
2323
cfgv2 "sigs.k8s.io/kubebuilder/v3/pkg/config/v2"
2424
cfgv3 "sigs.k8s.io/kubebuilder/v3/pkg/config/v3"
25+
declarativev1 "sigs.k8s.io/kubebuilder/v3/pkg/plugins/declarative/v1"
2526
pluginv2 "sigs.k8s.io/kubebuilder/v3/pkg/plugins/golang/v2"
2627
pluginv3 "sigs.k8s.io/kubebuilder/v3/pkg/plugins/golang/v3"
2728
)
@@ -30,14 +31,15 @@ func main() {
3031
c, err := cli.New(
3132
cli.WithCommandName("kubebuilder"),
3233
cli.WithVersion(versionString()),
33-
cli.WithDefaultProjectVersion(cfgv3.Version),
3434
cli.WithPlugins(
3535
&pluginv2.Plugin{},
3636
&pluginv3.Plugin{},
37+
&declarativev1.Plugin{},
3738
),
3839
cli.WithDefaultPlugins(cfgv2.Version, &pluginv2.Plugin{}),
3940
cli.WithDefaultPlugins(cfgv3.Version, &pluginv3.Plugin{}),
40-
cli.WithCompletion,
41+
cli.WithDefaultProjectVersion(cfgv3.Version),
42+
cli.WithCompletion(),
4143
)
4244
if err != nil {
4345
log.Fatal(err)

designs/extensible-cli-and-scaffolding-plugins-phase-1-5.md

Lines changed: 107 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,9 @@ The goal of this phase is to achieve one of the goals proposed for Phase 2: chai
88
Phase 2 includes several other challenging goals, but being able to chain plugins will be beneficial
99
for third-party developers that are using kubebuilder as a library.
1010

11+
The other main goal of phase 2, discovering and using external plugins, is out of the scope of this phase,
12+
and will be tackled when phase 2 is implemented.
13+
1114
## Table of contents
1215
- [Goal](#goal)
1316
- [Motivation](#motivation)
@@ -46,36 +49,42 @@ Plugin chaining solves the aforementioned problems but the current plugin API, a
4649

4750
Design a Plugin API that combines the current [`Subcommand`](../pkg/plugin/interfaces.go) and
4851
[`RunOptions`](../pkg/plugins/internal/cmdutil/cmdutil.go) interfaces and enables plugin-chaining.
49-
The new `Subcommand` methods can be split in two different categories:
50-
- Initialization methods
51-
- Execution methods
52+
The new `Subcommand` hooks can be split in two different categories:
53+
- Initialization hooks
54+
- Execution hooks
55+
56+
Initialization hooks are run during the dynamic creation of the CLI, which means that they are able to
57+
modify the CLI, e.g. providing descriptions and examples for subcommands or binding flags.
58+
Execution hooks are run after the CLI is created, and therefore cannot modify the CLI. On the other hand,
59+
as they are run during the CLI execution, they have access to user-provided flag values, project configuration,
60+
the new API resource or the filesystem abstraction, as opposed to the initialization hooks.
5261

53-
Additionally, some of these methods may be optional, in which case a non-implemented method will be skipped
54-
when it should be called and consider it succeeded. This also allows to create some methods specific for
55-
a certain subcommand call (e.g.: `Resource`-related methods for the `edit` subcommand are not needed).
62+
Additionally, some of these hooks may be optional, in which case a non-implemented hook will be skipped
63+
when it should be called and consider it succeeded. This also allows to create some hooks specific for
64+
a certain subcommand call (e.g.: `Resource`-related hooks for the `edit` subcommand are not needed).
5665

5766
Different ordering guarantees can be considered:
58-
- Method order guarantee: a method for a plugin will be called after its previous methods succeeded.
59-
- Steps order guarantee: methods will be called when all plugins have finished the previous method.
60-
- Plugin order guarantee: same method for each plugin will be called in the order specified
67+
- Hook order guarantee: a hook for a plugin will be called after its previous hooks succeeded.
68+
- Steps order guarantee: hooks will be called when all plugins have finished the previous hook.
69+
- Plugin order guarantee: same hook for each plugin will be called in the order specified
6170
by the plugin position at the plugin chain.
6271

63-
All of the methods will offer plugin order guarantee, as they all modify/update some item so the order
64-
of plugins is important. Execution methods need to guarantee step order, as the items that are being modified
72+
All of the hooks will offer plugin order guarantee, as they all modify/update some item so the order
73+
of plugins is important. Execution hooks need to guarantee step order, as the items that are being modified
6574
in each step (config, resource, and filesystem) are also needed in the following steps. This is not true for
66-
initialization methods that modify items (metadata and flagset) that are only used in their own methods,
67-
so they only need to guarantee method order.
75+
initialization hooks that modify items (metadata and flagset) that are only used in their own methods,
76+
so they only need to guarantee hook order.
6877

69-
Execution methods will be able to return an error. A specific error can be returned to specify that
70-
no further methods of this plugin should be called, but that the scaffold process should be continued.
78+
Execution hooks will be able to return an error. A specific error can be returned to specify that
79+
no further hooks of this plugin should be called, but that the scaffold process should be continued.
7180
This enables plugins to exit early, e.g., a plugin that scaffolds some files only for cluster-scoped
7281
resources can detect if the resource is cluster-scoped at one of the first execution steps, and
7382
therefore, use this error to tell the CLI that no further execution step should be called for itself.
7483

75-
### Initialization methods
84+
### Initialization hooks
7685

7786
#### Update metadata
78-
This method will be used for two purposes. It provides CLI-related metadata to the Subcommand (e.g.,
87+
This hook will be used for two purposes. It provides CLI-related metadata to the Subcommand (e.g.,
7988
command name) and update the subcommands metadata such as the description or examples.
8089

8190
- Required/optional
@@ -88,7 +97,7 @@ command name) and update the subcommands metadata such as the description or exa
8897
- [x] Create webhook
8998

9099
#### Bind flags
91-
This method will allow subcommands to define specific flags.
100+
This hook will allow subcommands to define specific flags.
92101

93102
- Required/optional
94103
- [ ] Required
@@ -102,7 +111,7 @@ This method will allow subcommands to define specific flags.
102111
### Execution methods
103112

104113
#### Inject configuration
105-
This method will be used to inject the `Config` object that the plugin can modify at will.
114+
This hook will be used to inject the `Config` object that the plugin can modify at will.
106115
The CLI will create/load/save this configuration object.
107116

108117
- Required/optional
@@ -115,7 +124,7 @@ The CLI will create/load/save this configuration object.
115124
- [x] Create webhook
116125

117126
#### Inject resource
118-
This method will be used to inject the `Resource` object.
127+
This hook will be used to inject the `Resource` object created by the CLI.
119128

120129
- Required/optional
121130
- [x] Required
@@ -127,9 +136,9 @@ This method will be used to inject the `Resource` object.
127136
- [x] Create webhook
128137

129138
#### Pre-scaffold
130-
This method will be used to take actions before the main scaffolding is performed, e.g. validations.
139+
This hook will be used to take actions before the main scaffolding is performed, e.g. validations.
131140

132-
NOTE: a filesystem abstraction will be passed to this method that must be used for scaffolding.
141+
NOTE: a filesystem abstraction will be passed to this hook, but it should not be used for scaffolding.
133142

134143
- Required/optional
135144
- [ ] Required
@@ -141,9 +150,9 @@ NOTE: a filesystem abstraction will be passed to this method that must be used f
141150
- [x] Create webhook
142151

143152
#### Scaffold
144-
This method will be used to perform the main scaffolding.
153+
This hook will be used to perform the main scaffolding.
145154

146-
NOTE: a filesystem abstraction will be passed to this method that must be used for scaffolding.
155+
NOTE: a filesystem abstraction will be passed to this hook that must be used for scaffolding.
147156

148157
- Required/optional
149158
- [x] Required
@@ -155,11 +164,14 @@ NOTE: a filesystem abstraction will be passed to this method that must be used f
155164
- [x] Create webhook
156165

157166
#### Post-scaffold
158-
This method will be used to take actions after the main scaffolding is performed, e.g. cleanup.
167+
This hook will be used to take actions after the main scaffolding is performed, e.g. cleanup.
159168

160-
NOTE: a filesystem abstraction will **NOT** be passed to this method, as post-scaffold task do not require it.
169+
NOTE: a filesystem abstraction will **NOT** be passed to this hook, as post-scaffold task do not require it.
161170
In case some post-scaffold task requires a filesystem abstraction, it could be added.
162171

172+
NOTE 2: the project configuration is saved by the CLI before calling this hook, so changes done to the
173+
configuration at this hook will not be persisted.
174+
163175
- Required/optional
164176
- [ ] Required
165177
- [x] Optional
@@ -168,10 +180,67 @@ In case some post-scaffold task requires a filesystem abstraction, it could be a
168180
- [x] Edit
169181
- [x] Create API
170182
- [x] Create webhook
183+
184+
### Override plugins for single subcommand calls
185+
186+
Defining plugins at initialization and using them for every command call will solve most of the cases.
187+
However, there are some cases where a plugin may be wanted just for a certain subcommand call. For
188+
example, a project with multiple controllers may want to follow the declarative pattern in only one of
189+
their controllers. The other case is also relevant, a project where most of the controllers follow the
190+
declarative pattern may need a single controller not to follow it.
191+
192+
In order to achieve this, the `--plugins` flag will be allowed in every command call, overriding the
193+
value used in its corresponging project initialization call.
194+
195+
### Plugin chain persistence
196+
197+
Currently, the project configuration v3 offers two mechanisms for storing plugin-related information.
198+
199+
- A layout field (`string`) that is used for plugin resolution on initialized projects.
200+
- A plugin field (`map[string]interface{}`) that is used for plugin configuration raw storage.
201+
202+
Plugin resolution uses the `layout` field to resolve plugins. In this phase, it has to store a plugin
203+
chain and not a single plugin. As this value is stored as a string, comma-separated representation can
204+
be used to represent a chain of plugins instead.
205+
206+
NOTE: commas are not allowed in the plugin key.
207+
208+
While the `plugin` field may seem like a better fit to store the plugin chain, as it can already
209+
contain multiple values, there are several issues with this alternative approach:
210+
- A map does not provide any order guarantee, and the plugin chain order is relevant.
211+
- Some plugins do not store plugin-specific configuration information, e.g. the `go`-plugins. So
212+
the absence of a plugin key doesn't mean that the plugin is not part of the plugin chain.
213+
- The desire of running a different set of plugins for a single subcommand call has already been
214+
mentioned. Some of these out-of-chain plugins may need to store plugin-specific configuration,
215+
so the presence of a plugin doesn't mean that is part of the plugin chain.
216+
217+
The next project configuration version could consider this new requirements to define the
218+
names/types of these two fields.
219+
220+
### Plugin bundle
221+
222+
As a side-effect of plugin chaining, the user experience may suffer if they need to provide
223+
several plugin keys for the `--plugins` flag. Additionally, this would also mean a user-facing
224+
important breaking change.
225+
226+
In order to solve this issue, a plugin bundle concept will be introduced. A plugin bundle
227+
behaves as a plugin:
228+
- It has a name: provided at creation.
229+
- It has a version: provided at creation.
230+
- It has a list of supported project versions: computed from the common supported project
231+
versions of all the plugins in the bundled.
232+
233+
Instead of implementing the optional getter methods that return a subcommand, it offers a way
234+
to retrieve the list of bundled plugins. This process will be done after plugin resolution.
235+
236+
This way, CLIs will be able to define bundles, which will be used in the user-facing API and
237+
the plugin resolution process, but later they will be treated as separate plugins offering
238+
the maintainability and separation of concerns advantages that smaller plugins have in
239+
comparison with bigger monolithic plugins.
171240

172241
## Implementation
173242

174-
The following types are used as input/output values of the described methods:
243+
The following types are used as input/output values of the described hooks:
175244
```go
176245
// CLIMetadata is the runtime meta-data of the CLI
177246
type CLIMetadata struct {
@@ -197,7 +266,7 @@ func (e ExitError) Error() string {
197266
}
198267
```
199268

200-
The described methods are implemented through the use of the following interfaces.
269+
The described hooks are implemented through the use of the following interfaces.
201270
```go
202271
type RequiresCLIMetadata interface {
203272
InjectCLIMetadata(CLIMetadata)
@@ -220,11 +289,11 @@ type RequiresResource interface {
220289
}
221290

222291
type HasPreScaffold interface {
223-
PreScaffold(afero.Fs) error
292+
PreScaffold(machinery.Filesystem) error
224293
}
225294

226295
type Scaffolder interface {
227-
Scaffold(afero.Fs) error
296+
Scaffold(machinery.Filesystem) error
228297
}
229298

230299
type HasPostScaffold interface {
@@ -256,3 +325,11 @@ type CreateWebhookSubcommand interface {
256325
Scaffolder
257326
}
258327
```
328+
329+
An additional interface defines the bundle method to return the wrapped plugins:
330+
```go
331+
type Bundle interface {
332+
Plugin
333+
Plugins() []Plugin
334+
}
335+
```

pkg/cli/internal/config/config_suite_test.go renamed to doc.go

Lines changed: 4 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -14,16 +14,8 @@ See the License for the specific language governing permissions and
1414
limitations under the License.
1515
*/
1616

17-
package config
17+
//go:generate go run github.com/markbates/pkger/cmd/pkger
1818

19-
import (
20-
"testing"
21-
22-
. "github.com/onsi/ginkgo"
23-
. "github.com/onsi/gomega"
24-
)
25-
26-
func TestCLI(t *testing.T) {
27-
RegisterFailHandler(Fail)
28-
RunSpecs(t, "Config Suite")
29-
}
19+
// Package kubebuilder contains pkged files compiled into the
20+
// go binaries.
21+
package kubebuilder

docs/book/src/component-config-tutorial/testdata/project/config/prometheus/monitor.yaml

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,10 @@ spec:
1111
endpoints:
1212
- path: /metrics
1313
port: https
14+
scheme: https
15+
bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
16+
tlsConfig:
17+
insecureSkipVerify: true
1418
selector:
1519
matchLabels:
1620
control-plane: controller-manager

0 commit comments

Comments
 (0)