Some distributions have no default write-access to this file, which
means that it's not possible to update the file and rebuild the project
if not write-able. This patch fixes this by adding an additional
`chmod`.
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
When we switched to go-runner for building the apiserver,
controller-manager, and scheduler server components, we no longer
reference the individual architectures in the image names, specifically
in the 'FROM' directive of the server image Dockerfiles.
As a result, server images for non-amd64 images copy in the go-runner
amd64 binary instead of the go-runner that matches that architecture.
This commit explicitly sets the '--platform=linux/${arch}' to ensure
we're pulling the correct go-runner arch from the manifest list.
Before:
FROM ${base_image}
After:
FROM --platform=linux/${arch} ${base_image}
Signed-off-by: Stephen Augustus <saugustus@vmware.com>
debian-base is no longer used for building core Kubernetes server
components, so we remove the unnecessary local variable referencing it
from kube::build::get_docker_wrapped_binaries().
Signed-off-by: Stephen Augustus <saugustus@vmware.com>
While the umask was previously set for builds (and in fact `docker run`
sets it to 0022 by default), the release pipeline `cp`'s files (with
`-a`) which respect the user's umask, and is outside of the build path.
This sets the umask in a common function called by all build tools,
which Stephen agreed was the simplest and most complete fix. The
`verify-prereqs` function is already poorly named for what it does, and
this only makes it epsilon worse.
The debian-iptables v12.0.0 build didn't work because of another
previously-undiscovered iptables 1.8.x bug. Work around it for now and
bump the version to v12.0.1; we can revert back to the original
version of the script once iptables 1.8.4 is available in
buster-backports.
default behavior does not change, it uses k8s.gcr.io by default
added two vars: KUBE_DOCKER_REGISTRY, KUBE_BASE_IMAGE_REGISTRY.
KUBE_BASE_IMAGE_REGISTRY is for base image registry of server binaries
KUBE_DOCKER_REGISTRY is for released images registry
user can interact with them by:
`KUBE_DOCKER_REGISTRY=### KUBE_BASE_IMAGE_REGISTRY=### make quick-release`
Signed-off-by: Hui Luo <luoh@vmware.com>
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.
Add ability to build with runtime coverage instrumentation
**What this PR does / why we need it**:
This PR adds the ability to instrument a subset of kubernetes binaries to report code coverage information. The specific use-case is to help determine coverage of our end-to-end Conformance tests, as well as provide data that can be used to help determine where to focus. This PR focuses on making it possible to build with instrumentation; collecting and using the generated coverage data will be done in later PRs. For more details as to the intent, see the [design doc](https://docs.google.com/document/d/1FKMBFxz7vtA-6ZgUkA47F8m6yR00fwqLcXMVJqsHt0g/edit?usp=sharing) (google doc; requires kubernetes-dev membership).
Specifically, this PR adds a new `KUBE_BUILD_WITH_COVERAGE` make variable, which when set will cause `kube-apiserver`, `kube-controller-manager`, `kube-scheduler`, `kube-proxy` and `kubelet` to be built with coverage instrumentation. These coverage-instrumented binaries will flush coverage information to disk every five seconds, defaulting to a temporary directory unless the `KUBE_COVERAGE_FILE` environment variable is set at launch, in which case it will write to that file instead.
The mechanism used to achieve coverage instrumentation is to build the targeted binaries as "unit tests" with coverage enabled, and then rigging the unit tests to just execute the binary's usual entry point. This is implemented only for the bash build system.
/sig testing
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 67396, 67097, 67395, 67365, 67099). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Update to debian-iptables v10.1 and hyperkube-base 0.10.1
**What this PR does / why we need it**: these images are based on the `debian-base` 0.3.2 images, which include CVE fixes (#67026) and permission fixes of the qemu-ARCH-static helper binary (#67026, #67283).
**Release note**:
```release-note
NONE
```
First version of this was only standalone, now the code is being
vendored by anyone who wants to use it. So the standalone binary and
container are no longer useful.
Change-Id: Ib9369de66b4ecb3451f73ba2a252526d6615b96f
Fix kubernetes build scripts to work in case the source directory is in
a directory path which contains a space.
You can prepare such a directory like this:
$ mkdir '/tmp/test dir/'
$ cd '/tmp/test dir/'
$ git clone https://github.com/kubernetes/kubernetes.git
$ cd kubernetes
Then, without the fix:
$ KUBE_FASTBUILD=true KUBE_RELEASE_RUN_TESTS=n build/release.sh
cat: /tmp/test: No such file or directory
cat: dir/kubernetes/build/build-image/cross/VERSION: No such file or directory
cat: /tmp/test: No such file or directory
cat: dír/kubernetes/build/build-image/VERSION: No such file or directory
+++ [0307 18:10:33] Verifying Prerequisites....
cp: target '/tmp/test dir/kubernetes/_output/images/kube-build:build-7c7cd10a18--/Dockerfile' is not a directory
!!! [0307 18:10:33] Call tree:
!!! [0307 18:10:33] 1: build/release.sh:35
kube::build::build_image(...)
!!! Error in build/../build/common.sh:454
Error in build/../build/common.sh:454. '((i<3-1))' exited with status 1
Call stack:
1: build/../build/common.sh:454 kube::build::build_image(...)
2: build/release.sh:35 main(...)
Exiting with status 1
With the fix the compilation succeeds. The fix is done adding double
quotes to required places (and also just in case to other places where
shellcheck recommended adding them).
Note that this fix doesn't help with the official make-based build:
it's tricky to make makefiles work with targets with spaces in their
names.
Automatic merge from submit-queue (batch tested with PRs 59705, 59207, 59677). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
build: fix a logic error in shell script.
**What this PR does / why we need it**: It looks like that there's a logic error in `build/common.sh`. The return value of a `docker inspect` command is not checked properly, since the value being assigned is actually the previous command's return value (a `0`, because `local` always returns `0` when used like this).
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
This is the 2nd attempt. The previous was reverted while we figured out
the regional mirrors (oops).
New plan: k8s.gcr.io is a read-only facade that auto-detects your source
region (us, eu, or asia for now) and pulls from the closest. To publish
an image, push k8s-staging.gcr.io and it will be synced to the regionals
automatically (similar to today). For now the staging is an alias to
gcr.io/google_containers (the legacy URL).
When we move off of google-owned projects (working on it), then we just
do a one-time sync, and change the google-internal config, and nobody
outside should notice.
We can, in parallel, change the auto-sync into a manual sync - send a PR
to "promote" something from staging, and a bot activates it. Nice and
visible, easy to keep track of.
The right place to assign the "docker inspect" return value is outside
of the subshell. The last return value was coming from something else
than the expected command.
Automatic merge from submit-queue (batch tested with PRs 54071, 58393). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Optionally launch build containers inside a specific parent cgroup
**What this PR does / why we need it**: Adds support to the build process for launching containers inside a specific parent cgroup via the `--cgroup-parent` docker arg. We needed this to enforce resource usage when building Kubernetes in our CI environment.
**Special notes for your reviewer**: None
**Release note**:
```release-note
NONE
```
