No idea why it blames lock during fetching.
```bash
...
* [new tag] v0.9.9 -> v0.9.9
error: cannot lock ref 'refs/tags/v0.6.3': Unable to create 'C:/Users/runneradmin/AppData/Local/Temp/tmp.N2FTxfARN9/.git/refs/tags/v0.6.3.lock': File exists.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
+ cleanup
+ rm -rf /tmp/tmp.N2FTxfARN9
```
Signed-off-by: Wei Fu <fuweid89@gmail.com>
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 <danny@dcantah.dev>
This moves all the release builds into a Dockerfile which is a bit
cleaner for setting up our build environment.
Non-linux/amd64 builds are cross-compiled.
Currently onlinux linux/amd64, linux/arm64, and windows/amd64 are
supported, but is easy to add more, provided their is a cross-compile
toolchain available for it.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Wei Fu