`dockerPusher` provides `pushWriter` which implements `content.Writer`.
However, even if `pushWriter` become abort status (i.e. `Close()` is called
before `Commit()`), `dockerPusher` doesn't recognise that status and treats that
writer as on-going.
This behaviour doesn't allow the client to retry an aborted push.
This commit fixes this issue.
This commit also adds an test to ensure that the issue is fixed.
Signed-off-by: Kohei Tokunaga <ktokunaga.mail@gmail.com>
* Adds Windows dockerfile for volume-ownership image
* Build volume-copy-up on Windows
* Adds a helper tool that fetches the owner username and SID of
a file or folder
* Adds README
* Remove 2004 from Windows versions
* Add ltsc2022 to Windows versions
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
This change adds a new workflow that builds the volume test images
and pushes them to a remote registry.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Following PR #6284, the Windows Periodic Workflow is prevented from
running on any repository outside of the original.
While this achieves the goal of preventing senseless Windows workflow
failures in contributors' forks, it makes running the workflow for
contributors (even manually) impossible.
This PR adds a separate workflow file which triggers the Windows
Integration workflow iff it is being run off of the original repository,
thus maintaining the upstream scheduling, while allowing contributors to
manually trigger the workflow on their forks if they so desire.
Signed-off-by: Nashwan Azhari <nazhari@cloudbasesolutions.com>
In the Windows CI's periodic runs the `azure/CLI` GitHub action library
is leveraged to run various Azure-related commands.
To avoid possible desyncing between the auth libraries of `azure/Login`
and `azure/CLI` as described
[here](https://github.com/Azure/cli/issues/56#issuecomment-958705517),
this patch neglects to pass an explicit `azcliversion` to `azure/CLI` in
order to have it default to the Azure CLI version set up by `azure/Login`.
Signed-off-by: Nashwan Azhari <nazhari@cloudbasesolutions.com>
When containerd use this config:
```
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."localhost:5000"]
endpoint = ["http://localhost:5000"]
```
Due to the `newTransport` function does not initialize the `TLSClientConfig` field.
Then use `TLSClientConfig` to cause nil pointer dereference
Signed-off-by: wanglei <wllenyj@linux.alibaba.com>
When running containerd as a service it may be hard to
override the TMP location of the process. This is especially
true on Windows when running containerd in SCM. This change
allows you to set the 'temp' location in the config.toml when
the service starts up that overrides its TEMP/TMP/TMPDIR usage.
This is helpful on Linux as well but it primarily solves the
performance issue on Windows when running containerd across
volumes. IE: If you configure your data/root paths on a volume
other than the SystemDrive the snapshotter does a temporary unpack
on the SystemDrive and then has to copy contents of that data
to the snapshot folder on the destination volume. By alinging the
tmp with the destination it is a simple move operation instead of
a copy operation.
Signed-off-by: Justin Terry <jlterry@amazon.com>
The current Windows CI setup script assumes it will always be run under
the `azureuser` username.
While this username is defined in the Windows CI GitHub action, the
current version of the script both exposes us to a future risk of
breaking should the CI action be changed, and is also unfriendly to
`curl | sh`-ing it for quick test environment setups.
This patch makes the Windows CI setup script work with any username
provided they have administrative privileges.
Signed-off-by: Nashwan Azhari <nazhari@cloudbasesolutions.com>
