In the Makefile doc for quick-release target, it says:
KUBE_FASTBUILD: Whether to cross-compile for other architectures. Set to 'true' to do so.
If should be "Set to false"
1. release-in-a-container - Like 'make release' but in a container.
2. cross-in-a-container - Like 'make cross' but in a container.
3. package-tarballs - (NEW) To package tarballs with a docker dependency
'release-in-a-container' is currently only for testing and is not slated to
be used, but may be useful for testing in some scenarios.
'cross-in-a-container' is meant to be run from the kube-cross image alone.
'package-tarballs' is a companion target that runs from a docker image
to package up the tarballs and images (from cross-in-a-container) for a release.
**What this PR does / why we need it**:
Makes functions in validation/schema.go private to kubectl,
further isolating kubectl.
**Which issue this PR fixes**
Part of a series of PRs to address kubernetes/community#598
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 48890, 46893, 48872, 48896)
Support customized system spec in the node conformance test and create the GKE system spec
ref: https://github.com/kubernetes/kubernetes/issues/46891
- System specs are located in `test/e2e_node/system/specs`. Created one for validating GKE images in `test/e2e_node/system/specs/gke.yaml`.
- `--image-spec-name` can be used to specify a system spec in node e2e and conformance tests. This option maps to `SYSTEM_SPEC_NAME` in a test properties file, which is the user facing configuration. So, users can specify `SYSTEM_SPEC_NAME=gke` to run the image validation using the GKE system spec.
- If `SYSTEM_SPEC_NAME` is unspecified, the default spec (`system.DefaultSysSpec`) will be used.
- We can also use `make test-e2e-node SYSTEM_SPEC_NAME=gke` to run tests using GKE image spec.
**Release note**:
`None`
Automatic merge from submit-queue
Add quick-verify make rule.
This is useful for humans to run to catch obvious problems before
pushing commits and waiting for CI to run verify checks.
Quick mode only runs a whitelist of verify scripts that are reasonably fast.
I set the initial bar arbitrarily at <10s each on my workstation.
The whole set runs in <30s for me, assuming I had already run `make` and
`hack/godep-restore.sh`. This is compared to the full `make verify`
which takes [I don't know how long because I gave up after 45min].
This is useful for humans to run to catch obvious problems before
pushing commits and waiting for CI to run verify checks.
Quick mode only runs a whitelist of verify scripts that are reasonably fast.
I set the initial bar arbitrarily at <10s each on my workstation.
The whole set runs in <30s for me, assuming I had already run `make` and
`hack/godep-restore.sh`. This is compared to the full `make verify`
which takes [I don't know how long because I gave up after 45min].
Automatic merge from submit-queue (batch tested with PRs 47921, 45984, 46829, 46896, 46923)
Remove unnecessary wrapper flags
**What this PR does / why we need it**:
Drop KUBE_GOFLAGS, KUBE_GOGCFLAGS, KUBE_GOLDFLAGS references
from the build infrastructure
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#47296
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
This commit ensures that:
- go vet will be run as part of the make verify target
- the vet make-rule script won't be run directly, as generated_files won't be run in that case
- that go vet errors show up in the build log with a start time, finish time, and SUCCESS/FAILED message as part of the verify make rule script
Drop KUBE_GOFLAGS, KUBE_GOGCFLAGS, KUBE_GOLDFLAGS references
from the build infrastructure. There are some usages still
for KUBE_GOFLAGS, so we should print a deprecation message
until all those are fixed. If both KUBE_GOFLAGS and GOFLAGS
are just then we just bail out.
Ghe Rivero