This repository has been archived by the owner on Jul 30, 2021. It is now read-only.
Run make target #141
Merged
Run make target #141
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added make target that combines building, resetting the VM, and provisioning it with bootkube. Installs archives to speed up go builds.
ethernetdan
force-pushed
the
run-step
branch
from
50bb0ff to
9e2e89e
Compare
aaronlevy
reviewed
Sep 23, 2016
| @cd hack/$*-node && ./bootkube-up | ||
| @echo "Bootkube ready" | ||
|
|
||
| clean-vm-single: |
There was a problem hiding this comment.
Is this still necessary with the clean-vm-% pattern?
There was a problem hiding this comment.
It's hacky but the named targets were taking precedence over the wildcard ones. Any idea of a better way to do this?
There was a problem hiding this comment.
Not sure I understand the underlying issue. Doesn't seem like any other named targets would match clean-vm- -- and I would assume clean-vm-% would catch clean-vm-single -- but I might be misundestanding the issue. Not a big deal as-is - just making sure I understand.
| clean-vm-single: | ||
| clean-vm-%: | ||
| @echo "Cleaning VM..." | ||
| @(cd hack/single-node && vagrant destroy -f && vagrant up) & |
There was a problem hiding this comment.
Might also want to add rm -rf cluster/ -- otherwise you could have compiled bootkube with new asset templates, but bootkube-up will not overwrite them if directory already exists.
There was a problem hiding this comment.
good catch and I agree on cluster
|
This is great! Could you add a short blurb to the README that describes the use? |
Removed cluster folder with object manifests when using 'run-single' or 'run-multi' in order to ensure Bootkube uses fresh manifests. Added explanation of run-* functionality to README Fixed multi-node (was mistakenly hard coded to use single node)
ethernetdan
force-pushed
the
run-step
branch
from
1073146 to
9aa1673
Compare
aaronlevy
approved these changes
Dec 30, 2016
wking
added a commit
to wking/bootkube
that referenced
this pull request
Mar 29, 2018
'clean' has been a prerequisite for: * conformance-%, since the target landed in 0520bdf (hack: add conformance tests for hack builds, 2016-05-26, kubernetes-retired#45). * release, since the target landed in 04848d1 (Add release build process, 2016-05-27, kubernetes-retired#47). clean-vm-% target has been a prerequisite for run-% since the target landed in 9e2e89e (run make target, 2016-09-23, kubernetes-retired#141). But there are two problems with including cleaners are prerequisites of build steps: * They are inefficient. Make is good at rebuilding only things that need rebuilding, provided you inform it of your dependencies. Cleaning before every build will often lead to unnecessary rebuilds of up-to-date content. * They are racy. For example, a parallel make invocation may process several prerequisites at once. The current 'clean' recipe will execute quickly, which is why it hasn't been much of a problem yet, but you can see the race by inserting a delay: clean: sleep 60 rm -rf _output and running: $ make -j8 release sleep 60 mkdir -p _output/bin/darwin/ GOOS=darwin GOARCH=amd64 go build ... ... mkdir -p _output/release/ tar czf _output/release/bootkube.tar.gz -C _output bin/linux/bootkube bin/darwin/bootkube bin/linux/checkpoint rm -rf _output with the other preqrequisites completing first, clean's rm ends up removing everything release generated. In this commit, I've removed the clean prerequisites from the build targets to resolve the above issues. I've also updated our recommended make invocations to add clean as an explicit earlier step. This ensures folks following our directions get the same behavior as they would have previously (since our recommendations are all implicitly -j1 and rm is fast anyway). I think the extra clean calls may be overkill in at least some cases, but I'll remove them one by one in follow-up commits.
wking
added a commit
to wking/bootkube
that referenced
this pull request
Apr 3, 2018
'clean' has been a prerequisite for: * conformance-%, since the target landed in 0520bdf (hack: add conformance tests for hack builds, 2016-05-26, kubernetes-retired#45). * release, since the target landed in 04848d1 (Add release build process, 2016-05-27, kubernetes-retired#47). clean-vm-% target has been a prerequisite for run-% since the target landed in 9e2e89e (run make target, 2016-09-23, kubernetes-retired#141). But there are two problems with including cleaners are prerequisites of build steps: * They are inefficient. Make is good at rebuilding only things that need rebuilding, provided you inform it of your dependencies. Cleaning before every build will often lead to unnecessary rebuilds of up-to-date content. * They are racy. For example, a parallel make invocation may process several prerequisites at once. The current 'clean' recipe will execute quickly, which is why it hasn't been much of a problem yet, but you can see the race by inserting a delay: clean: sleep 60 rm -rf _output and running: $ make -j8 release sleep 60 mkdir -p _output/bin/darwin/ GOOS=darwin GOARCH=amd64 go build ... ... mkdir -p _output/release/ tar czf _output/release/bootkube.tar.gz -C _output bin/linux/bootkube bin/darwin/bootkube bin/linux/checkpoint rm -rf _output with the other preqrequisites completing first, clean's rm ends up removing everything release generated. In this commit, I've removed the clean prerequisites from the build targets to resolve the above issues. We could also update our recommended make invocations to add clean as an explicit earlier step, and I've done that for 'all' and 'run-' to hint at the existence of the clean targets. I don't think we need separate clean calls for 'release' or 'conformance-%' * No need to 'make clean' before calling 'make release' For Travis, the test environment should not include anything in _output at this point, so there's no need to call clean there. The 'clean' target has been included in .travis.yml since 1f34600 (Add travis tests, 2016-05-27, kubernetes-retired#46). And 'clean' had been a 'release' prerequisite since 04848d1 (Add release build process, 2016-05-27, kubernetes-retired#47). But neither of those motivate the Travis use-case, so I think they were just being overly cautious. And for RELEASING, walking the prerequisite chain for release shows that a clean all would have no impact: * check is verifying the source, and does not care about _output. * _output/release/bootkube.tar.gz knows about its dependencies. * _output/bin/% (used for _output/bin/.../bootkube) knows about its GOFILES and (new in this commit) VENDOR_GOFILES dependencies. This is *overly* broad, because it includes cmd/checkpoint/*.go and other non-dependencies, but overly broad is still safe. * The new VENDOR_GOFILES ensures we rebuild _output/bin/... if a vendored dependency is bumped even if no bootkube-specific code is bumped. * No need to 'make clean' before calling 'make conformance-...' The hack/ content only depends on _output for _output/bin/${local_os}/bootkube and _output/bin/linux/bootkube. conformance-% only uses hack/ content, and it depends on all. 'all', in turn, depends on both _output/bin/$(LOCAL_OS)/bootkube and _output/bin/linux/bootkube, and each of those fully specifies their build dependencies. So there's no need for a separate clean step before running the conformance-% targets; Make will rebuild anything that needs rebuilding already.
wking
added a commit
to wking/bootkube
that referenced
this pull request
Apr 3, 2018
'clean' has been a prerequisite for: * conformance-%, since the target landed in 0520bdf (hack: add conformance tests for hack builds, 2016-05-26, kubernetes-retired#45). * release, since the target landed in 04848d1 (Add release build process, 2016-05-27, kubernetes-retired#47). clean-vm-% target has been a prerequisite for run-% since the target landed in 9e2e89e (run make target, 2016-09-23, kubernetes-retired#141). But there are two problems with including cleaners are prerequisites of build steps: * They are inefficient. Make is good at rebuilding only things that need rebuilding, provided you inform it of your dependencies. Cleaning before every build will often lead to unnecessary rebuilds of up-to-date content. * They are racy. For example, a parallel make invocation may process several prerequisites at once. The current 'clean' recipe will execute quickly, which is why it hasn't been much of a problem yet, but you can see the race by inserting a delay: clean: sleep 60 rm -rf _output and running: $ make -j8 release sleep 60 mkdir -p _output/bin/darwin/ GOOS=darwin GOARCH=amd64 go build ... ... mkdir -p _output/release/ tar czf _output/release/bootkube.tar.gz -C _output bin/linux/bootkube bin/darwin/bootkube bin/linux/checkpoint rm -rf _output with the other preqrequisites completing first, clean's rm ends up removing everything release generated. In this commit, I've removed the clean prerequisites from the build targets to resolve the above issues. We could also update our recommended make invocations to add clean as an explicit earlier step, and I've done that for 'all' and 'run-' to hint at the existence of the clean targets. I don't think we need separate clean calls for 'release' or 'conformance-%' * No need to 'make clean' before calling 'make release' For Travis, the test environment should not include anything in _output at this point, so there's no need to call clean there. The 'clean' target has been included in .travis.yml since 1f34600 (Add travis tests, 2016-05-27, kubernetes-retired#46). And 'clean' had been a 'release' prerequisite since 04848d1 (Add release build process, 2016-05-27, kubernetes-retired#47). But neither of those motivate the Travis use-case, so I think they were just being overly cautious. And for RELEASING, walking the prerequisite chain for release shows that a clean all would have no impact: * check is verifying the source, and does not care about _output. * _output/release/bootkube.tar.gz knows about its dependencies. * _output/bin/% (used for _output/bin/.../bootkube) knows about its GOFILES and (new in this commit) VENDOR_GOFILES dependencies. This is *overly* broad, because it includes cmd/checkpoint/*.go and other non-dependencies, but overly broad is still safe. * The new VENDOR_GOFILES ensures we rebuild _output/bin/... if a vendored dependency is bumped even if no bootkube-specific code is bumped. * No need to 'make clean' before calling 'make conformance-...' The hack/ content only depends on _output for _output/bin/${local_os}/bootkube and _output/bin/linux/bootkube. conformance-% only uses hack/ content, and it depends on all. 'all', in turn, depends on both _output/bin/$(LOCAL_OS)/bootkube and _output/bin/linux/bootkube, and each of those fully specifies their build dependencies. So there's no need for a separate clean step before running the conformance-% targets; Make will rebuild anything that needs rebuilding already.
wking
added a commit
to wking/bootkube
that referenced
this pull request
May 16, 2018
'clean' has been a prerequisite for: * conformance-%, since the target landed in 0520bdf (hack: add conformance tests for hack builds, 2016-05-26, kubernetes-retired#45). * release, since the target landed in 04848d1 (Add release build process, 2016-05-27, kubernetes-retired#47). clean-vm-% target has been a prerequisite for run-% since the target landed in 9e2e89e (run make target, 2016-09-23, kubernetes-retired#141). But there are two problems with including cleaners are prerequisites of build steps: * They are inefficient. Make is good at rebuilding only things that need rebuilding, provided you inform it of your dependencies. Cleaning before every build will often lead to unnecessary rebuilds of up-to-date content. * They are racy. For example, a parallel make invocation may process several prerequisites at once. The current 'clean' recipe will execute quickly, which is why it hasn't been much of a problem yet, but you can see the race by inserting a delay: clean: sleep 60 rm -rf _output and running: $ make -j8 release sleep 60 mkdir -p _output/bin/darwin/ GOOS=darwin GOARCH=amd64 go build ... ... mkdir -p _output/release/ tar czf _output/release/bootkube.tar.gz -C _output bin/linux/bootkube bin/darwin/bootkube bin/linux/checkpoint rm -rf _output with the other preqrequisites completing first, clean's rm ends up removing everything release generated. In this commit, I've removed the clean prerequisites from the build targets to resolve the above issues. We could also update our recommended make invocations to add clean as an explicit earlier step, and I've done that for 'all' and 'run-' to hint at the existence of the clean targets. I don't think we need separate clean calls for 'release' or 'conformance-%' * No need to 'make clean' before calling 'make release' For Travis, the test environment should not include anything in _output at this point, so there's no need to call clean there. The 'clean' target has been included in .travis.yml since 1f34600 (Add travis tests, 2016-05-27, kubernetes-retired#46). And 'clean' had been a 'release' prerequisite since 04848d1 (Add release build process, 2016-05-27, kubernetes-retired#47). But neither of those motivate the Travis use-case, so I think they were just being overly cautious. And for RELEASING, walking the prerequisite chain for release shows that a clean all would have no impact: * check is verifying the source, and does not care about _output. * _output/release/bootkube.tar.gz knows about its dependencies. * _output/bin/% (used for _output/bin/.../bootkube) knows about its GOFILES and (new in this commit) VENDOR_GOFILES dependencies. This is *overly* broad, because it includes cmd/checkpoint/*.go and other non-dependencies, but overly broad is still safe. * The new VENDOR_GOFILES ensures we rebuild _output/bin/... if a vendored dependency is bumped even if no bootkube-specific code is bumped. * No need to 'make clean' before calling 'make conformance-...' The hack/ content only depends on _output for _output/bin/${local_os}/bootkube and _output/bin/linux/bootkube. conformance-% only uses hack/ content, and it depends on all. 'all', in turn, depends on both _output/bin/$(LOCAL_OS)/bootkube and _output/bin/linux/bootkube, and each of those fully specifies their build dependencies. So there's no need for a separate clean step before running the conformance-% targets; Make will rebuild anything that needs rebuilding already.
wking
added a commit
to wking/bootkube
that referenced
this pull request
Aug 17, 2018
'clean' has been a prerequisite for: * conformance-%, since the target landed in 0520bdf (hack: add conformance tests for hack builds, 2016-05-26, kubernetes-retired#45). * release, since the target landed in 04848d1 (Add release build process, 2016-05-27, kubernetes-retired#47). clean-vm-% target has been a prerequisite for run-% since the target landed in 9e2e89e (run make target, 2016-09-23, kubernetes-retired#141). But there are two problems with including cleaners are prerequisites of build steps: * They are inefficient. Make is good at rebuilding only things that need rebuilding, provided you inform it of your dependencies. Cleaning before every build will often lead to unnecessary rebuilds of up-to-date content. * They are racy. For example, a parallel make invocation may process several prerequisites at once. The current 'clean' recipe will execute quickly, which is why it hasn't been much of a problem yet, but you can see the race by inserting a delay: clean: sleep 60 rm -rf _output and running: $ make -j8 release sleep 60 mkdir -p _output/bin/darwin/ GOOS=darwin GOARCH=amd64 go build ... ... mkdir -p _output/release/ tar czf _output/release/bootkube.tar.gz -C _output bin/linux/bootkube bin/darwin/bootkube bin/linux/checkpoint rm -rf _output with the other preqrequisites completing first, clean's rm ends up removing everything release generated. In this commit, I've removed the clean prerequisites from the build targets to resolve the above issues. We could also update our recommended make invocations to add clean as an explicit earlier step, and I've done that for 'all' and 'run-' to hint at the existence of the clean targets. I don't think we need separate clean calls for 'release' or 'conformance-%' * No need to 'make clean' before calling 'make release' For Travis, the test environment should not include anything in _output at this point, so there's no need to call clean there. The 'clean' target has been included in .travis.yml since 1f34600 (Add travis tests, 2016-05-27, kubernetes-retired#46). And 'clean' had been a 'release' prerequisite since 04848d1 (Add release build process, 2016-05-27, kubernetes-retired#47). But neither of those motivate the Travis use-case, so I think they were just being overly cautious. And for RELEASING, walking the prerequisite chain for release shows that a clean all would have no impact: * check is verifying the source, and does not care about _output. * _output/release/bootkube.tar.gz knows about its dependencies. * _output/bin/% (used for _output/bin/.../bootkube) knows about its GOFILES and (new in this commit) VENDOR_GOFILES dependencies. This is *overly* broad, because it includes cmd/checkpoint/*.go and other non-dependencies, but overly broad is still safe. * The new VENDOR_GOFILES ensures we rebuild _output/bin/... if a vendored dependency is bumped even if no bootkube-specific code is bumped. * No need to 'make clean' before calling 'make conformance-...' The hack/ content only depends on _output for _output/bin/${local_os}/bootkube and _output/bin/linux/bootkube. conformance-% only uses hack/ content, and it depends on all. 'all', in turn, depends on both _output/bin/$(LOCAL_OS)/bootkube and _output/bin/linux/bootkube, and each of those fully specifies their build dependencies. So there's no need for a separate clean step before running the conformance-% targets; Make will rebuild anything that needs rebuilding already.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added make target that combines building, resetting the VM, and
provisioning it with bootkube to make iterating faster.
Installs Go archives to speed up builds.