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>
This patch standardizes the capitalization of PowerShell commandlets in
the Windows CI setup script in accordance with general PowerShell best
practices.
Signed-off-by: Nashwan Azhari <nazhari@cloudbasesolutions.com>
In prior releases we were not using this variable and instead were
self-constructing a release tar file.
This was changed in 27d7c50384
The change means the variable is being used now and is causing the
artifacts to be produced to have a different name which may break
download scripts.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
