Change:
I spent quite a while figuring out how to build the docker images for k8s, when I finally succeeded, the build process told me the images are deleted. I was quite puzzled: After I built the images again. only to receive the same message, I started digging, and I found out that the images are exported with . I think a notification where the images are found would be useful. If you do it a couple of times you remember this, but for newcomers or the occasional contributor this can be very frustrating. A log message I'm happy to submit a PR, if you think this is useful.
FWIW all output goes under , I think we should ensure this is sufficiently documented at least.
It took me a while to find this. Also, I tried using the scripts directly without much success. The makefile is much more helpful. It might be worth mentioning that in the linked document.
i had the same problem
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale /help /triage accepted /kind documentation /retitle document _output directory though also a log message might be good? thing is where to stick it, we have a lot of variations on building that won't pass through the same codepaths ... IMO this absolutely ought to be documented at the very least
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /remove-lifecycle stale /help /triage accepted /kind documentation /retitle document _output directory though also a log message might be good? thing is where to stick it, we have a lot of variations on building that won't pass through the same codepaths ... IMO this absolutely ought to be documented at the very least Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
to begin with, I only a note about the location of the build artifacts. The is referenced already in many places in the developer guide. Maybe it is better to completely remove the mentioning of manual invocation of the individual scripts and instead recommend the specific make target? IMHO, this is more consistent with the rest of the documentation. However, it is definitely out of scope here. If you or other dev's think it is a good idea, I can submit another PR for that.
completely remove the mentioning of manual invocation of the individual scripts and instead recommend the specific make target? Generally I think this is true, but there are some specific scripts in the repo where it can make sense to just invoke them directly and a few that are not in the makefile at all (like ) so it doesn't necessarily apply to everything, but I'd agree it generally applies to building at least. And I think that it would be good to make this more consistent
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Ping. Can this be merged?
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
All Docker names are suffixed with a hash derived from the file path (to allow concurrent usage on things like CI machines) and a version number.  When the version number changes all state is cleared and clean build is started.  This allows the build infrastructure to be changed and signal to CI systems that old artifacts need to be deleted. <ins> ## Build artifacts The build system output all its products to a top level directory in the source repository named `_output`. These include the binary compiled packages (e.g. kubectl, kube-scheduler etc.) and archived Docker images. If you intend to run a component with a docker image you will need to import it from this directory with the appropriate command (e.g. `docker import _output/release-images/amd64/kube-scheduler.tar k8s.io/kube-scheduler:$(git describe)`). </ins> ## Releasing The [`build/release.sh`](release.sh) script will build a release.  It will build binaries, run tests, (optionally) build runtime Docker images.

```bash SOURCE_DATE_EPOCH=$(git show -s --format=format:%ct HEAD) <del> ``` </del>  No newline at end of file <ins> ``` </ins>