Merge pull request #1 from mytunguyen/testing

Testing

.github/workflows/verify.yml

@@ -0,0 +1,14 @@
+on:
+  pull_request_target:
+    types: [opened, edited, reopened]
+
+jobs:
+  verify:
+    runs-on: ubuntu-latest
+    name: verify PR contents
+    steps:
+    - name: Verifier action
+      id: verifier
+      uses: kubernetes-sigs/[email protected]
+      with:
+        github_token: ${{ secrets.GITHUB_TOKEN }}

.gitignore

@@ -11,6 +11,10 @@ out
 # Test binary, build with `go test -c`
 *.test
 
+# E2E test templates
+test/e2e/data/infrastructure-docker/v1alpha3/cluster-template*.yaml
+test/e2e/data/infrastructure-docker/v1alpha4/cluster-template*.yaml
+
 # Output of the go coverage tool, specifically when used with LiteIDE
 *.out
 

CONTRIBUTING.md

@@ -26,7 +26,7 @@ Read the following guide if you're interested in contributing to cluster-api.
 We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles.
 
 Please fill out either the individual or corporate Contributor License Agreement (CLA). More information about the CLA
-and instructions for signing it [can be found here](https://github.com/kubernetes/community/blob/master/CLA.md).
+and instructions for signing it [can be found here](https://git.k8s.io/community/CLA.md).
 
 ***NOTE***: Only original source code from you and other people that have signed the CLA can be accepted into the
 *repository.
@@ -36,14 +36,14 @@ and instructions for signing it [can be found here](https://github.com/kubernete
 If you're new to the project and want to help, but don't know where to start, we have a semi-curated list of issues that
 should not need deep knowledge of the system. [Have a look and see if anything sounds
 interesting](https://github.com/kubernetes-sigs/cluster-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22).
-Before starting to work on the issue, make sure that it doesn't have a [lifecycle/active](https://github.com/kubernetes-sigs/cluster-api/labels/lifecycle%2Factive) label. If the issue has been assigned, reach out to the assignee. 
+Before starting to work on the issue, make sure that it doesn't have a [lifecycle/active](https://github.com/kubernetes-sigs/cluster-api/labels/lifecycle%2Factive) label. If the issue has been assigned, reach out to the assignee.
 Alternatively, read some of the docs on other controllers and try to write your own, file and fix any/all issues that
 come up, including gaps in documentation!
 
 ## Contributing a Patch
 
 1. If you haven't already done so, sign a Contributor License Agreement (see details above).
-1. If working on an issue, signal other contributors that you are actively working on it using `/lifecycle active`.  
+1. If working on an issue, signal other contributors that you are actively working on it using `/lifecycle active`.
 1. Fork the desired repo, develop and test your code changes.
 1. Submit a pull request.
     1. All code PR must be labeled with one of
@@ -54,28 +54,64 @@ come up, including gaps in documentation!
         - 🌱 (:seedling:, minor or other)
 
 All changes must be code reviewed. Coding conventions and standards are explained in the official [developer
-docs](https://github.com/kubernetes/community/tree/master/contributors/devel). Expect reviewers to request that you
+docs](https://git.k8s.io/community/contributors/devel). Expect reviewers to request that you
 avoid common [go style mistakes](https://github.com/golang/go/wiki/CodeReviewComments) in your PRs.
 
+## Releases
+
+Cluster API uses [GitHub milestones](https://github.com/kubernetes-sigs/cluster-api/milestones) to track releases.
+
+- Minor versions CAN be planned and scheduled twice in a calendar year.
+  - Each minor version is preceded with one or more planning session.
+  - Planning consists of one or more backlog grooming meetings, roadmap amendments,
+    and CAEP proposal reviews.
+- Patch versions CAN be planned and scheduled each month for each of the currently supported series (usually N and N-1).
+- Code freeze is in effect 72 hours (3 days) before a release.
+  - Maintainers should communicate the code freeze date at a community meeting preceding the code freeze date.
+  - Only critical bug fixes may be merged in between freeze & release.
+    - Each bug MUST be associated with an open issue and properly triaged.
+    - PRs MUST be approved by at least 2 project maintainers.
+      - First approver should `/approve` and `/hold`.
+      - Second approver should `/approve` and `/hold cancel`.
+  - [E2E Test grid](https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api#capi%20e2e%20tests) SHOULD be green before cutting a release.
+- Dates in a release are approximations and always subject to change.
+- `Next` milestone is for work that has been triaged, but not prioritized/accepted for any release.
+
+## Proposal process (CAEP)
+
+The Cluster API Enhacement Proposal is the process this project uses to adopt new features, changes to the APIs, changes to contracts between components, or changes to CLI interfaces.
+
+The [template](https://github.com/kubernetes-sigs/cluster-api/blob/master/docs/proposals/YYYYMMDD-template.md), and accepted proposals live under [docs/proposals](https://github.com/kubernetes-sigs/cluster-api/tree/master/docs/proposals).
+
+- Proposals or requests for enhacements (RFEs) MUST be associated with an issue.
+  - Issues can be placed on the roadmap during planning if there is one or more folks
+    that can dedicate time to writing a CAEP and/or implementating it after approval.
+- A proposal SHOULD be introduced and discussed during the weekly community meetings,
+  [Kubernetes SIG Cluster Lifecycle mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle),
+  or [discuss forum](https://discuss.kubernetes.io/c/contributors/cluster-api/).
+  - Submit and discuss proposals using a collaborative writing platform, preferably Google Docs, share documents with edit permissions with the [Kubernetes SIG Cluster Lifecycle mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle).
+- A proposal in a Google Doc MUST turn into a [Pull Request](https://github.com/kubernetes-sigs/cluster-api/pulls).
+- Proposals MUST be merged and in `implementable` state to be considered part of a major or minor release.
+
 ## Triaging E2E test failures
 
-When you submit a change to the Cluster API repository as set of validation jobs is automatically executed by 
+When you submit a change to the Cluster API repository as set of validation jobs is automatically executed by
 prow and the results report is added to a comment at the end of your PR.
 
-Some jobs run linters or unit test, and in case of failures, you can repeat the same operation locally using `make test lint-full [etc..]` 
-in order to investigate and potential issues. Prow logs usually provide hints about the make target you should use  
-(there might be more than one command that needs to be run).  
+Some jobs run linters or unit test, and in case of failures, you can repeat the same operation locally using `make test lint-full [etc..]`
+in order to investigate and potential issues. Prow logs usually provide hints about the make target you should use
+(there might be more than one command that needs to be run).
 
 End-to-end (E2E) jobs create real Kubernetes clusters by building Cluster API artifacts with the latest changes.
 In case of E2E test failures, usually it's required to access the "Artifacts" link on the top of the prow logs page to triage the problem.
 
 The artifact folder contains:
 - A folder with the clusterctl local repository used for the test, where you can find components yaml and cluster templates.
-- A folder with logs for all the clusters created during the test. Following logs/info are available: 
+- A folder with logs for all the clusters created during the test. Following logs/info are available:
     - Controller logs (only if the cluster is a management cluster).
     - Dump of the Cluster API resources (only if the cluster is a management cluster).
     - Machine logs (only if the cluster is a workload cluster)
-    
+
 In case you want to run E2E test locally, please refer to the [Testing](https://cluster-api.sigs.k8s.io/developer/testing.html#running-the-end-to-end-tests) guide.
 
 ## Reviewing a Patch
@@ -96,7 +132,7 @@ Code reviews should generally look at:
 - **Comments**: Are the comments clear and useful? Do they explain the why rather than what?
 - **Documentation**: Did the developer also update relevant documentation?
 
-See [Code Review in Cluster API](REVIEWING.md) for a more focused list of review items. 
+See [Code Review in Cluster API](REVIEWING.md) for a more focused list of review items.
 
 ### Approvals
 
@@ -109,27 +145,24 @@ process.
 
 ## Backporting a Patch
 
-Cluster API maintains older versions through `release-X.Y` branches. We accept backports of bug fixes to the most recent
-release branch. For example, if the most recent branch is `release-0.2`, and the `master` branch is under active
-development for v0.3.0, a bug fix that merged to `master` that also affects `v0.2.x` may be considered for backporting
-to `release-0.2`. We generally do not accept PRs against older release branches.
+Cluster API maintains older versions through `release-X.Y` branches.
+We accept backports of bug fixes and non breaking features to the most recent release branch.
+Backports MUST not be breaking for both API and behavioral changes.
+We generally do not accept PRs against older release branches.
 
-## Features and bugs
+As an example:
 
-Open [issues](https://github.com/kubernetes-sigs/cluster-api/issues/new/choose) to report bugs, or minor features.
+  Let's assume that the most recent release branch is `release-0.3`
+  and the main branch is under active development for the next release.
+  A pull request that has been merged in the main branch can be backported to the `release-0.3`
+  if at least one maintainer approves the cherry pick, or asks the PR's author to backport.
 
-For big feature, API and contract amendments, we follow the CAEP process as outlined below.
 
-## Proposal process (CAEP)
+## Features and bugs
 
-The Cluster API Enhacement Proposal is the process this project uses to adopt new features, or changes to the APIs.
+Open [issues](https://github.com/kubernetes-sigs/cluster-api/issues/new/choose) to report bugs, or minor features.
 
-- The template, and accepted proposals live under `docs/proposals`.
-- A proposal SHOULD be introduced and discussed during the weekly community meetings,
-  [Kubernetes SIG Cluster Lifecycle mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle),
-  or [discuss forum](https://discuss.kubernetes.io/c/contributors/cluster-api/).
-- A proposal SHOULD be submitted first to the community using a collaborative writing platform, preferably Google Docs.
-  - When using Google Docs, share the document with edit permissions for the [Kubernetes SIG Cluster Lifecycle mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle).
+For big feature, API and contract amendments, we follow the CAEP process as outlined below.
 
 ## Experiments
 
@@ -213,7 +246,7 @@ against the kubernetes/org repo.
 
 However, if you are a member of any of the related Kubernetes GitHub organizations but not of the Kubernetes org, you
 will need explicit sponsorship for your membership request. You can read more about Kubernetes membership and
-sponsorship [here](https://github.com/kubernetes/community/blob/master/community-membership.md).
+sponsorship [here](https://git.k8s.io/community/community-membership.md).
 
 Cluster API maintainers can assign you an issue or pull request by leaving a `/assign <your Github ID>` comment on the
 issue or pull request.

Dockerfile

@@ -1,4 +1,4 @@
-# syntax=docker/dockerfile:experimental
+# syntax=docker/dockerfile:1.1-experimental
 
 # Copyright 2018 The Kubernetes Authors.
 #
@@ -15,7 +15,7 @@
 # limitations under the License.
 
 # Build the manager binary
-FROM golang:1.13.15 as builder
+FROM golang:1.15.7 as builder
 WORKDIR /workspace
 
 # Run this with docker build --build_arg goproxy=$(go env GOPROXY) to override the goproxy
@@ -29,13 +29,15 @@ COPY go.sum go.sum
 
 # Cache deps before building and copying source so that we don't need to re-download as much
 # and so that source changes don't invalidate our downloaded layer
-RUN go mod download
+RUN --mount=type=cache,target=/go/pkg/mod \
+    go mod download
 
 # Copy the sources
 COPY ./ ./
 
 # Cache the go build into the the Go’s compiler cache folder so we take benefits of compiler caching across docker build calls
 RUN --mount=type=cache,target=/root/.cache/go-build \
+    --mount=type=cache,target=/go/pkg/mod \
     go build .
 
 # Build
@@ -45,13 +47,15 @@ ARG ldflags
 
 # Do not force rebuild of up-to-date packages (do not use -a) and use the compiler cache folder
 RUN --mount=type=cache,target=/root/.cache/go-build \
+    --mount=type=cache,target=/go/pkg/mod \
     CGO_ENABLED=0 GOOS=linux GOARCH=${ARCH} \
     go build -ldflags "${ldflags} -extldflags '-static'" \
     -o manager ${package}
 
 # Production image
-FROM gcr.io/distroless/static:latest
+FROM gcr.io/distroless/static:nonroot
 WORKDIR /
 COPY --from=builder /workspace/manager .
-USER nobody
+# Use uid of nonroot user (65532) because kubernetes expects numeric user when applying pod security policies
+USER 65532
 ENTRYPOINT ["/manager"]