Update the cronjob-tutorial project files

Signed-off-by: Martin Hickey <[email protected]>

docs/book/src/cronjob-tutorial/gvks.md

@@ -46,9 +46,9 @@ a package.
 Now that we have our terminology straight, we can *actually* create our
 API!
 
-## So, how can we create our API? 
+## So, how can we create our API?
 
-In the next section, [Adding a new API](./cronjob-tutorial/new-api.html) we will check how the tool help us to create our own API's with the command `kubebuilder create api`.
+In the next section, [Adding a new API](../cronjob-tutorial/new-api.html) we will check how the tool help us to create our own API's with the command `kubebuilder create api`.
 
 The goal of this command is to create Custom Resource (CR) and Custom Resource Definition (CRD) for our Kind(s). To check it further see; [Extend the Kubernetes API with CustomResourceDefinitions][kubernetes-extend-api].
 

docs/book/src/cronjob-tutorial/new-api.md

@@ -8,6 +8,8 @@ controller, we can use `kubebuilder create api`:
 kubebuilder create api --group batch --version v1 --kind CronJob
 ```
 
+Press `y` for "Create Resource" and "Create Controller".
+
 The first time we call this command for each group-version, it will create
 a directory for the new group-version.
 

docs/book/src/cronjob-tutorial/testdata/emptyapi.go

@@ -1,4 +1,5 @@
 /*
+Copyright 2021.
 
 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.

docs/book/src/cronjob-tutorial/testdata/emptycontroller.go

@@ -1,4 +1,5 @@
 /*
+Copyright 2021.
 
 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.
@@ -24,10 +25,10 @@ package controllers
 import (
 	"context"
 
-	"github.com/go-logr/logr"
 	"k8s.io/apimachinery/pkg/runtime"
 	ctrl "sigs.k8s.io/controller-runtime"
 	"sigs.k8s.io/controller-runtime/pkg/client"
+	"sigs.k8s.io/controller-runtime/pkg/log"
 
 	batchv1 "tutorial.kubebuilder.io/project/api/v1"
 )
@@ -41,7 +42,6 @@ objects, so these are added out of the box.
 // CronJobReconciler reconciles a CronJob object
 type CronJobReconciler struct {
 	client.Client
-	Log    logr.Logger
 	Scheme *runtime.Scheme
 }
 
@@ -78,7 +78,7 @@ some pairs at the top of our reconcile method to have those attached to all log
 lines in this reconciler.
 */
 func (r *CronJobReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
-	_ = r.Log.WithValues("cronjob", req.NamespacedName)
+	_ = log.FromContext(ctx)
 
 	// your logic here
 

docs/book/src/cronjob-tutorial/testdata/emptymain.go

@@ -1,4 +1,5 @@
 /*
+Copyright 2021 The Kubernetes authors.
 
 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.

docs/book/src/cronjob-tutorial/testdata/generate_cronjob.sh

@@ -52,7 +52,7 @@ function gen_cronjob_tutorial {
   mkdir project
   cd project
   header_text "creating tutorial.kubebuilder.io base  ..."
-  kubebuilder init --domain=tutorial.kubebuilder.io --project-version=3-alpha --repo=tutorial.kubebuilder.io/project --license apache2 --owner "The Kubernetes authors"
+  kubebuilder init --domain tutorial.kubebuilder.io --repo tutorial.kubebuilder.io/project --license apache2 --owner "The Kubernetes authors"
   kubebuilder create api --group batch --version v1 --kind CronJob --resource --controller
   kubebuilder create webhook --group batch --version v1 --kind CronJob --defaulting --programmatic-validation
 }

docs/book/src/cronjob-tutorial/testdata/project/Makefile

@@ -3,6 +3,8 @@
 IMG ?= controller:latest
 # Produce CRDs that work back to Kubernetes 1.11 (no version conversion)
 CRD_OPTIONS ?= "crd:trivialVersions=true,preserveUnknownFields=false"
+# ENVTEST_K8S_VERSION refers to the version of kubebuilder assets to be downloaded by envtest binary.
+ENVTEST_K8S_VERSION = 1.21
 
 # Get the currently used golang install path (in GOPATH/bin, unless GOBIN is set)
 ifeq (,$(shell go env GOBIN))
@@ -49,11 +51,8 @@ fmt: ## Run go fmt against code.
 vet: ## Run go vet against code.
 	go vet ./...
 
-ENVTEST_ASSETS_DIR=$(shell pwd)/testbin
-test: manifests generate fmt vet ## Run tests.
-	mkdir -p ${ENVTEST_ASSETS_DIR}
-	test -f ${ENVTEST_ASSETS_DIR}/setup-envtest.sh || curl -sSLo ${ENVTEST_ASSETS_DIR}/setup-envtest.sh https://raw.githubusercontent.com/kubernetes-sigs/controller-runtime/v0.7.2/hack/setup-envtest.sh
-	source ${ENVTEST_ASSETS_DIR}/setup-envtest.sh; fetch_envtest_tools $(ENVTEST_ASSETS_DIR); setup_envtest_env $(ENVTEST_ASSETS_DIR); go test ./... -coverprofile cover.out
+test: manifests generate fmt vet envtest ## Run tests.
+	KUBEBUILDER_ASSETS="$(shell $(ENVTEST) use $(ENVTEST_K8S_VERSION) -p path)" go test ./... -coverprofile cover.out
 
 ##@ Build
 
@@ -87,12 +86,16 @@ undeploy: ## Undeploy controller from the K8s cluster specified in ~/.kube/confi
 
 CONTROLLER_GEN = $(shell pwd)/bin/controller-gen
 controller-gen: ## Download controller-gen locally if necessary.
-	$(call go-get-tool,$(CONTROLLER_GEN),sigs.k8s.io/controller-tools/cmd/controller-gen@v0.5.0)
+	$(call go-get-tool,$(CONTROLLER_GEN),sigs.k8s.io/controller-tools/cmd/controller-gen@v0.6.1)
 
 KUSTOMIZE = $(shell pwd)/bin/kustomize
 kustomize: ## Download kustomize locally if necessary.
 	$(call go-get-tool,$(KUSTOMIZE),sigs.k8s.io/kustomize/kustomize/[email protected])
 
+ENVTEST = $(shell pwd)/bin/setup-envtest
+envtest: ## Download envtest-setup locally if necessary.
+	$(call go-get-tool,$(ENVTEST),sigs.k8s.io/controller-runtime/tools/setup-envtest@latest)
+
 # go-get-tool will 'go get' any package $2 and install it to $1.
 PROJECT_DIR := $(shell dirname $(abspath $(lastword $(MAKEFILE_LIST))))
 define go-get-tool

docs/book/src/cronjob-tutorial/testdata/project/api/v1/cronjob_types.go

@@ -33,31 +33,31 @@ import (
 // +kubebuilder:docs-gen:collapse=Imports
 
 /*
-First, let's take a look at our spec.  As we discussed before, spec holds
-*desired state*, so any "inputs" to our controller go here.
+ First, let's take a look at our spec.  As we discussed before, spec holds
+ *desired state*, so any "inputs" to our controller go here.
 
-Fundamentally a CronJob needs the following pieces:
+ Fundamentally a CronJob needs the following pieces:
 
-- A schedule (the *cron* in CronJob)
-- A template for the Job to run (the
-*job* in CronJob)
+ - A schedule (the *cron* in CronJob)
+ - A template for the Job to run (the
+ *job* in CronJob)
 
-We'll also want a few extras, which will make our users' lives easier:
+ We'll also want a few extras, which will make our users' lives easier:
 
-- A deadline for starting jobs (if we miss this deadline, we'll just wait till
-  the next scheduled time)
-- What to do if multiple jobs would run at once (do we wait? stop the old one? run both?)
-- A way to pause the running of a CronJob, in case something's wrong with it
-- Limits on old job history
+ - A deadline for starting jobs (if we miss this deadline, we'll just wait till
+   the next scheduled time)
+ - What to do if multiple jobs would run at once (do we wait? stop the old one? run both?)
+ - A way to pause the running of a CronJob, in case something's wrong with it
+ - Limits on old job history
 
-Remember, since we never read our own status, we need to have some other way to
-keep track of whether a job has run.  We can use at least one old job to do
-this.
+ Remember, since we never read our own status, we need to have some other way to
+ keep track of whether a job has run.  We can use at least one old job to do
+ this.
 
-We'll use several markers (`// +comment`) to specify additional metadata.  These
-will be used by [controller-tools](https://github.com/kubernetes-sigs/controller-tools) when generating our CRD manifest.
-As we'll see in a bit, controller-tools will also use GoDoc to form descriptions for
-the fields.
+ We'll use several markers (`// +comment`) to specify additional metadata.  These
+ will be used by [controller-tools](https://github.com/kubernetes-sigs/controller-tools) when generating our CRD manifest.
+ As we'll see in a bit, controller-tools will also use GoDoc to form descriptions for
+ the fields.
 */
 
 // CronJobSpec defines the desired state of CronJob
@@ -106,10 +106,10 @@ type CronJobSpec struct {
 }
 
 /*
-We define a custom type to hold our concurrency policy.  It's actually
-just a string under the hood, but the type gives extra documentation,
-and allows us to attach validation on the type instead of the field,
-making the validation more easily reusable.
+ We define a custom type to hold our concurrency policy.  It's actually
+ just a string under the hood, but the type gives extra documentation,
+ and allows us to attach validation on the type instead of the field,
+ making the validation more easily reusable.
 */
 
 // ConcurrencyPolicy describes how the job will be handled.
@@ -132,12 +132,12 @@ const (
 )
 
 /*
-Next, let's design our status, which holds observed state.  It contains any information
-we want users or other controllers to be able to easily obtain.
+ Next, let's design our status, which holds observed state.  It contains any information
+ we want users or other controllers to be able to easily obtain.
 
-We'll keep a list of actively running jobs, as well as the last time that we successfully
-ran our job.  Notice that we use `metav1.Time` instead of `time.Time` to get the stable
-serialization, as mentioned above.
+ We'll keep a list of actively running jobs, as well as the last time that we successfully
+ ran our job.  Notice that we use `metav1.Time` instead of `time.Time` to get the stable
+ serialization, as mentioned above.
 */
 
 // CronJobStatus defines the observed state of CronJob
@@ -155,9 +155,9 @@ type CronJobStatus struct {
 }
 
 /*
-Finally, we have the rest of the boilerplate that we've already discussed.
-As previously noted, we don't need to change this, except to mark that
-we want a status subresource, so that we behave like built-in kubernetes types.
+ Finally, we have the rest of the boilerplate that we've already discussed.
+ As previously noted, we don't need to change this, except to mark that
+ we want a status subresource, so that we behave like built-in kubernetes types.
 */
 
 //+kubebuilder:object:root=true