remove remap-rootfs bin when running make clean#4139
remove remap-rootfs bin when running make clean#4139AkihiroSuda merged 2 commits intoopencontainers:mainfrom
Conversation
lifubang
added
easy-to-review
backport/1.1-todo
cyphar
left a comment
cyphar
left a comment
There was a problem hiding this comment.
LGTM, though I wonder if it would be better to have a per-contrib-cmd Makefile (and move the .gitignore entries while we're at it). Then again, we configure the go build line fairly heavily so maybe that wouldn't work too well...
| .PHONY: clean | ||
| clean: |
There was a problem hiding this comment.
Was there a reason you moved this to a different location in the Make file? (it makes it harder to see what changed)
There was a problem hiding this comment.
I think the idea is to make it harder to miss when we add new targets in the future:
So I think move the target clean next to all will reduce such type error in the future?
There was a problem hiding this comment.
Ah, yeah, probably; was considering 2 commits (one that moves it, and one that updates it), but not a hard blocker.
There was a problem hiding this comment.
Thanks!
Another think, as @kolyshkin asked in #4140 (comment) , I think we should make one more 1.1.x release because of the issue #4122 . But it's very hard to backport #4124 to release-1.1 , because in this PR, there are two topics in one commit, while one topic of them is not in release-1.1. @cyphar
lifubang
force-pushed
the
fix-clean-remap-rootfs
branch
from
253c2f4 to
960bc7e
Compare
lifubang
removed
the
backport/1.1-todo
Signed-off-by: lfbzhm <lifubang@acmcoder.com>
Signed-off-by: lfbzhm <lifubang@acmcoder.com>
lifubang
force-pushed
the
fix-clean-remap-rootfs
branch
from
f16fea3 to
c811308
Compare
cyphar
left a comment
cyphar
left a comment
There was a problem hiding this comment.
LGTM, though I think splitting the makefile might make more sense (we can do that in a future PR).
4 participants
I have reviewed and found such errors for about 2 times.
So I think move the target
cleannext toallwill reduce such type error in the future?