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. |
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 |
…909-origin-release-v3.28 Automated cherry pick of #8909: Rebuild containernetworking binaries, so we don't need to
Do the same for flannel-cni-plugin as projectcalico#8909 did for containernetworking-plugins, i.e. clone the repo and build using the go-build image from the calico monorepo on-demand. This is done to remove the tedious step of creating new releases and updating the Makefile with the new version on the flannel-cni-plugin repo.
Do the same for flannel-cni-plugin as projectcalico#8909 did for containernetworking-plugins, i.e. clone the repo and build using the go-build image from the calico monorepo on-demand. This is done to remove the tedious step of creating new releases and updating the Makefile with the new version on the flannel-cni-plugin repo.
…909-origin-release-v3.27 Automated cherry pick of #8909: Rebuild containernetworking binaries, so we don't need to
Do the same for flannel-cni-plugin as projectcalico#8909 did for containernetworking-plugins, i.e. clone the repo and build using the go-build image from the calico monorepo on-demand. This is done to remove the tedious step of creating new releases and updating the Makefile with the new version on the flannel-cni-plugin repo.
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.