Windows: Supply windows shim version via file#9019
Windows: Supply windows shim version via file#9019samuelkarp merged 1 commit intocontainerd:mainfrom
Conversation
|
Skipping CI for Draft Pull Request. |
dcantah
force-pushed
the
hcsshim-version
branch
from
c6022da to
cbd3bb8
Compare
Somewhat similar to how we supply the version of runc to grab for testing via a file in script/, this change supplies the Windows shim version to build off of via a file in the same directory. This seems like a decent home given it now lives next to the script that pulls and builds the shim to include in our build artifacts/locally. The motivation behind this change is: Cut down on unneccessary hcsshim vendorings if no library code for containerd changed. It was some what clunky how the Windows builds work today. The Windows shim is developed out of tree at github.com/microsoft/hcsshim. To let containerd know what tag to build the shim off of we'd vendor hcsshim into containerd, and then parse the version string from go.mod, fetch this tag, and then build the shim and include it in our artifacts. As mentioned, often times the vendoring would bring in no actual changes that would affect containerd's usage of hcsshim as a library, and would just serve as a means to bump the version of the containerd shim we should build. Now this process can be a one line change and we can avoid the possible headaches that come with bumping go.mod (bumping other unrelated deps etc.) Signed-off-by: Danny Canter <[email protected]>
dcantah
force-pushed
the
hcsshim-version
branch
from
cbd3bb8 to
15b13fb
Compare
|
@kevpar Agreed, this was not in response to that. I saw @thaJeztah mention this model and went and did a dive on how many hcsshim vendors this would've saved just from myself. I came to the conclusion this was probably worth it after I got to 4 😅 |
|
post-merge LGTM, thank you!!!
Yes, the main goal of this would be to make it more clear that the Being able to update them separately means that
|
chrishenzie
added
the
cherry-picked/1.7.x
7 participants
Somewhat similar to how we supply the version of runc to grab for testing via a file in script/, this change supplies the Windows shim version to build off of via a file in the same directory. This seems like a decent home given it now lives next to the script that pulls and builds the shim to include in our build artifacts/locally.
The motivation behind this change is:
Cut down on unneccessary hcsshim vendorings if no library code for containerd changed. It was somewhat clunky how the Windows builds work today. The Windows shim is developed out of tree at github.com/microsoft/hcsshim. To let containerd know what tag to build the shim off of we'd vendor hcsshim into containerd, and then parse the version string from go.mod, fetch this tag, and then build the shim and include it in our artifacts. As mentioned, often times the vendoring would bring in no actual changes that would affect containerd's usage of hcsshim as a library, and would just serve as a means to bump the version of the containerd shim we should build.
Now this process can be a one line change and we can avoid the possible headaches that come with bumping go.mod (bumping other unrelated deps etc.)
Note
To try and show how this would've faired if this was always the model, here are some of my personal hcsshim bumps that would not have been needed as the changes we wanted were in the shim itself and not any library functionality that changed (although some of them do include changes to exported code, it was not the reason for the bump/containerd doesn't use any of the symbols/functionality):