Change:
<ins> #!/bin/bash # Copyright 2017 The Kubernetes Authors. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. source "${KUBE_ROOT}/hack/lib/util.sh" CLEAN_PATTERNS=( "_tmp" "doc_tmp" ".*/zz_generated.openapi.go" "test/e2e/generated/bindata.go" ) for pattern in ${CLEAN_PATTERNS[@]}; do for match in $(find "${KUBE_ROOT}" -iregex "^${KUBE_ROOT}/${pattern}$"); do echo "Removing ${match#${KUBE_ROOT}/} .." rm -rf "${match#${KUBE_ROOT}/}" done done # ex: ts=2 sw=2 et filetype=sh </ins>

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: After setting up an IntelliJ project files for the Kubernetes repo, I had IntelliJ related project files in the directory. Wanting to clean up some generated files, I ran . I was surprised to see that my IntelliJ project files were deleted as well. What you expected to happen: I would have expected to remove only files generated by kubernetes development commands. I would not have expected it to not delete files that I created and intended to be long-lasting, but were only usable by me, and thus gitignored. How to reproduce it (as minimally and precisely as possible): Create a IntelliJ project for Kubernetes that places or files in the repo. Run . The IntelliJ project will be deleted. Anything else we need to know?: I'm not entirely ensure what the correct behavior is here. I see the change to use was made recently by in this . The reasons stated in the pr make a lot of sense to me. However, I think this doesn't cover the edge case in which a file is gitignored because it should be long-lasting and it will be unique to each development environment, and thus should not be removed on every . I'd love to work on figuring out the proper behavior here, and submitting a pr to fix - please let me know how I can help :)
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig contributor-experience
I'd be interested if you have any suggestions of what to do here. There's a few file system workarounds (such as having your dir outside of the project and symlinking it in.. then you'd just have to restore the symlink after a . I think it's more the assumption that it would only remove build artifacts, rather than removing all temp/.gitignored files.
I'm not super unfamiliar with idiomatic files, so part of this may be my misunderstanding.

My assumption was would remove artifacts that could've been created by some make command (i.e. ). I wouldn't have assumed it would remove all files. What about having a which only removes files generated by and then a (or or ) which removes any gitignored files? Thanks for your help with this :)
Agree on should only remove those things it created by itself (can be any make sub-commands in Makefile). It'd better not remove other files (even if they're untracked) which may be created by users or user tools. Maybe we can create a blacklist file which includes those things created by and should be removed by .
that sounds like a good plan to me - what would you think of that is a fix? My understanding is that that would be similar to what was in place before, except before the list was missing artifacts we wanted to remove.
I think it's just a difference in assumption around what the command does. When I run "make clean" I want to ensure that that my working copy doesn't have any files that may change or interfere with a build. To me, this is any files we don't check into the repo. Maintaining a list of files that is safe to clean leaves us open to the list falling out of date (which it previously did, which is why the functionality was changed in the first place).
Yeah, I think you make a great point that it seems like there are two different interpretations of what does. I'm not super familiar with - do you know which one is the more "traditional" interpretation? One thing I think about is that it seems slightly more dangerous to delete too many, instead of too few files - one operation is very easy to address, whereas the other isn't. I think that leads me to prefer a slightly less aggressive . Thoughts on if it would be helpful for me to write a pr so we have some concrete code to base this chat on?
My opinion is that deletes only things that were generated by something did. If I want to delete other files I created, I call instead.
oh, but we're using , which only deletes ignored files. that's better, though still potentially unexpected.
I created a with an optional different implementation so we could have something to compare the current behavior too.

Let me know your thoughts :)
IMO, The point of moving to using was that anything in your dir that isn't a part of the checked in repo has the potential to impact the build. Temp files, generated files, _output directories, etc. The previous functionality maintained a smaller, manual list that did become out of date (not just in theory), and caused problems. I'm open to solutions, but I don't feel great about returning to a manual list as that's what broke things in the first place.
You make a great point about the manual white list becoming out of date - and I think its particularly convincing that that's happened in practice. I have two ideas: you think that having two options - and - like in the diff - helps address this? The typical developer can use on their local system, while automated processes creating builds can use ? , what if instead of having a whitelist of files to delete, we had a blacklist of files not to delete? This solves the issue which caused me to report this "bug" and the potential drift of the blacklist seems much less concerning. Do either of those sound preferable? If so, I'll update my pr. Thanks for your thought on this :)
I believe this is a bug introduced by , therefore mark this as a bug instead of feature. etcd will also be removed by , which isn't right. cc
where is the local etcd being stored? do you have details on the bug?
Are you talking about builds that take place outside of a docker container (or bazel sandbox)? I don't think we should offer any guarantees about getting a good build outside of docker or a bazel sandbox. If our containerized build is pulling in the wrong files, though, it seems we could fix that by writing code that is more specific about what it includes.
Yeah this is a terrible thing to do to people, I have all sorts of stuff in some of my kubernetes directories that I would not be happy if make clean obliterated.
I have dozens of utility shell scripts and example yaml files that are ignored via . I lost all of them after T_T
etcd installed by hack/install- is in .gitignore too, and therefore gets deleted by :
Got it. Yeah, that's a problem. I opened to move to a back to a static list of files to clean.

It is more correct than a revert as it adds missing patterns, and it's safer than an .