Tools Bin #181
Tools Bin #181
Conversation
|
/hold |
openshift-ci
bot
added
the
do-not-merge/hold
|
/unhold |
openshift-ci
bot
removed
the
do-not-merge/hold
|
|
||
| ## Location to install dependencies to | ||
| LOCALBIN ?= $(shell pwd)/bin | ||
| LOCALBIN ?= $(shell pwd)/hack/tools/bin |
There was a problem hiding this comment.
Wondering if this is a bit too long; in k8s repos, the scripts are located directly in the hack directory, and then we add the tools and bin directory, all of which end up as synonyms of each other? Perhaps something shorter?
(Not a fan of the name of the directory, but it's what k8s does... shrug)
There was a problem hiding this comment.
It's setup this way to give us an option in the future of declaring our go tools via go.mod file in hack/tools/, then when those are pulled down they'll go in hack/tools/bin/. Makes it a bit easier to manage with our .gitignore files IMO.
.goreleaser.yml
Outdated
| hooks: | ||
| pre: | ||
| - mkdir -p bin |
There was a problem hiding this comment.
Is bin only a concern for goreleaser because of the make build task? If so, WDYT about calling mkdir -p bin in the make build recipe prior to calling goreleaser?
There was a problem hiding this comment.
It's needed for everything that runs goreleaser, including the release target, so I figured I'd build it into the yaml so it would always be there regardless of how/which make was called.
There was a problem hiding this comment.
including the release target
Ah, I didn't know this. How does it come into play with make release? (I thought that target used <projectRoot>/dist exclusively.)
There was a problem hiding this comment.
I stand corrected, you were right on this one; I've updated it to just call mkdir -p bin when running the build target.
.gitignore
Outdated
| *.dylib | ||
| bin/* | ||
| testbin/* | ||
| hack/tools/bin/* |
There was a problem hiding this comment.
IMO, we should be more explicit in some of these cases. IIRC, leaving the leading slash out means that we will ignore any path under the current dir that ends with hack/tools/bin/*. Whereas including the leading slash means just this specific directory from the root (based on the location of the gitignore file). IMO explicitness is almost always better.
There's a reasonable argument one could make about doing this more ubiquitously for all relevant .gitignore paths in a single PR, so this is non-blocking, regardless.
| hack/tools/bin/* | |
| /hack/tools/bin/* |
There was a problem hiding this comment.
Fully in agreement here, I'll add your suggestion. Thanks!
| use: buildx | ||
| build_flag_templates: | ||
| - "--platform=linux/amd64" |
There was a problem hiding this comment.
Need to rebase to pick this fix back up?
3 participants
Separates the tools binaries out to their own folder so we can stop doing funky stuff to ignore them when building the operator-controller image.