Rebuild containernetworking binaries, so we don't need to create rele… #8909
Conversation
marvin-tigera
added
release-note-required
cni-plugin/Makefile
Outdated
| git clone --single-branch --branch $(CNI_VERSION) https://github.com/projectcalico/containernetworking-plugins.git | ||
| touch $@ | ||
|
|
||
| $(CONTAINERNETWORKING_PLUGINS_CREATED): $(CONTAINERNETWORKING_PLUGINS_CLONED) |
There was a problem hiding this comment.
Not sure it's any cleaner(!) but there's a way to tell make that this target makes several binaries on a single invocation:
.../bin/foo .../bin/bar .../bin/baz &: $(TOUCHFILE)
...
The &: means "one call to this creates all these files"
I used that in the BPF builds to avoid issues when calling through to the BPF makefile.
There was a problem hiding this comment.
I took over your suggestion. I think it does look slightly cleaner now. Thanks for teaching me this feature.
I'll make the changes, but don't think the necessity is that high. The binaries are built on every merge job and so the (hash) releases will always have the latest go. Other than golang updates, this repo has been dead for years. For the same reason do I think that we don't need to ever update the CNI_VERSION any longer. |
| @@ -25,7 +25,8 @@ WINFV_SRCFILES=$(shell find win_tests -name '*.go') | |||
| # fail if unable to download | |||
| CURL=curl -C - -sSf | |||
|
|
|||
| # Use forked CNI plugin URL and corresponding tagged artifacts. | |||
| # The CNI plugin code that will be cloned and rebuilt with this repo's go-build image | |||
| # whenever the cni-plugin image is created. | |||
| CNI_VERSION=v1.1.1-calico+go-1.22.3 | |||
There was a problem hiding this comment.
suggestion (maybe unrelated): how about we move this version to metadata.mk?
Thanks, you're right that release builds should always be clean, but developers use makefiles too, and it's not sustainable for us to maintain an ever growing mental list of "things the makefile can't handle". I really don't want to have to run |
We never moved https://github.com/projectcalico/containernetworking-plugins to the monorepo, because the long-term vision is to use upstream. Because of this, we need to make a new release to this project every time a new golang patch comes out.
I added some automation to download the code of the project and rebuild it with go-build from the monorepo, thereby removing this tedious step of creating new releases and updating the makefile with the new version.