Dan and Sascha are senior Release Managers, SIG Release leadership, and
have already been giving thoughtful reviews of the content in this
directory.
Adding them as reviewers to spread the load of SIG Release eyes on
content.
Signed-off-by: Stephen Augustus <foo@auggie.dev>
The `-q` flag is not implemented by `docker buildx`, which results in an
output:
```
WARN[0000] quiet currently not implemented.
```
In the same way, the build output is not logged to `stdout` (but
`stderr`). This means we now dump the whole build process to a file and
if the `docker buildx` command fails, then we output those logs by
printing the contents of that file. This will also reduce the overall
verbosity and aligns to the original `docker build` behavior.
Signed-off-by: Sascha Grunert <mail@saschagrunert.de>
In order to use buildx with docker versions prior to v20.10 experimental
features must be enabled. Setting at build time ensures that they are
in case they have not already been at the environment scope.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
Both images are now sane multi-architecture images and should fix the
kube-proxy container image in the same way.
Signed-off-by: Sascha Grunert <mail@saschagrunert.de>
We cannot have any RUN commands in the Windows stage when using docker buildx,
which is why we were using the busybox-helper image. The purpose of the image
was to contain a few things that we would obtain by running a few commands:
- symlinks for the busybox binary
- run vcredist_x64.exe which would also give us the vcruntime140.dll which is
necessary for dig or httpd.
There are alternatives to the commands above that can be achieved in a Linux stage
as well:
- we can create the symlinks in a Linux stage with ln -s. Copying them over to
Windows will allow them to work just as well as if they were being copied over
from a Windows image. The 'Files\' prefix issue to the symlink target still persists.
- we can download the vcruntime140.dll directly, allowing us to skip the vcredist_x64.exe
installation.
The alternative to this would be to special-case code-generator. Since
it legit wants codegen, it seems wrong to make it be _examples (which tools
should ignore).
Make examples an "internal module" so the main go.mod for
k8s.io/code-generator does not get too polluted.
Because this comment is in a `define` which is later evaluated, the
syntactical `$(eval)` is treated like a variable exapansion. Just
change the comment.
Driving towards `make --warn-undefined-variables`.
The ``.container-$OS-$ARCH`` make subaction is creating files with the same name, and ``clean`` is meant to delete them. However, the ``clean``'s rm regex is not quite correct.
In d9cfd77149 and
d70d04f92b we added support for
reproducible builds for individual binaries (like kube-apiserver),
however we need to thread this support when we build binaries with
docker as well (say during "make quick-release").
Essentially, if GOLDFLAGS is set explicitly by someone either to a valid
value they would like to use or empty ("") then we pick that up. If it
is not set we should avoid setting GOLDFLAGS to empty. This ensures that
we support the same functionality documented here:
https://github.com/kubernetes/kubernetes/blob/master/build/root/Makefile#L82-L85
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
