Add CI to sig-win-dev-tools

[jayunit100]

We have no github actions! we need ... something?

• can we make windows VMs in github actions ?
• or should we use a vagrant cloud provider or something ?

[dougsland]

Hi @jayunit100,

Unfortunately Github Actions doesn't support VT-x flag:

==> controlplane: Clearing any previously set network interfaces...
==> controlplane: Preparing network interfaces based on configuration...
    controlplane: Adapter 1: nat
    controlplane: Adapter 2: hostonly
==> controlplane: Forwarding ports...
    controlplane: 22 (guest) => 2222 (host) (adapter 1)
==> controlplane: Running 'pre-boot' VM customizations...
==> controlplane: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "af6d8f40-2a53-411a-9c6a-cb49ded533a2", "--type", "headless"]

Stderr: VBoxManage: error: VT-x is not available (VERR_VMX_NO_VMX)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole
make: *** [Makefile:42: 2-vagrant-up] Error 1
Error: Process completed with exit code 2.

A possible solution: Allocate some machines 24/7 with VTx and add these machines as Self-host workers (Github runner)

[dougsland]

Another point to consider, adjust the network classes, GitHub Actions currectly complains about 10.20.30.x already set in the scripts. It's trivial change as showed here:

diff --git a/sync/linux/controlplane.sh b/sync/linux/controlplane.sh
index 070db0b..f88a05f 100644
--- a/sync/linux/controlplane.sh
+++ b/sync/linux/controlplane.sh
@@ -21,7 +21,7 @@ if [[ "$1" == "" || "$2" == "" ]]; then
   cat << EOF
     Missing args.
     You need to send kubernetes_version, k8s_kubelet_nodeip i.e.
-    ./controlplane.sh 1.21 10.20.30.10
+    ./controlplane.sh 1.21 192.168.56.10
     Normally these are in your variables.yml, and piped in by Vagrant.
     So, check that you didn't break the Vagrantfile :)
     BTW the only reason this error message is fancy is because friedrich said we should be curteous to people who want to
diff --git a/sync/shared/variables.yaml b/sync/shared/variables.yaml
index e409610..f63fae5 100644
--- a/sync/shared/variables.yaml
+++ b/sync/shared/variables.yaml
@@ -5,12 +5,12 @@ kubernetes_version: "1.25"
 build_from_source: "false"
 
 ## Linux settings
-k8s_linux_kubelet_nodeip: "10.20.30.10"
+k8s_linux_kubelet_nodeip: "192.168.56.10"
 linux_ram: 4096
 linux_cpus: 4
 
 ## Windows settings
-windows_node_ip: "10.20.30.11"
+windows_node_ip: "192.168.56.11"
 windows_ram: 6048
 windows_cpus: 4
 
diff --git a/sync/windows/1-antrea.ps1 b/sync/windows/1-antrea.ps1
index 47e06a1..004d3ab 100644
--- a/sync/windows/1-antrea.ps1
+++ b/sync/windows/1-antrea.ps1
@@ -15,7 +15,7 @@ limitations under the License.
 #>
 Param(
     [parameter(HelpMessage="Windows Node IP")]
-    [string] $windowsNodeIP = "10.20.30.11"
+    [string] $windowsNodeIP = "192.168.56.11"
 )
 $ErrorActionPreference = 'Stop'

[dougsland]

Here a demo GitHub Actions for the project: sig-windows-dev-tools> mkdir -p .github/workflows/ sig-windows-dev-tools> cat .github/workflows/initialtest.yml

name: Run Tests

on:
  workflow_dispatch:
  push:
    branches: [ main ]
  pull_request:
    branches:
      - main
jobs:
  initialtest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run tests
        run: |
          sudo curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
          sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
          sudo apt-get update
          sudo apt install build-essential vagrant virtualbox -y
          sudo vagrant plugin install vagrant-reload vagrant-vbguest winrm winrm-elevated vagrant-ssh
          make all

As mentioned above, even with the network class change, GH Actions still doesn't support VT-x. As soon it supports, it should work out of box.

[dougsland]

@jayunit100 please let me know your thoughts.

[jayunit100]

ah great find thanks doug

[jayunit100]

ah looking https://github.blog/changelog/2022-09-01-github-actions-larger-runners-are-now-in-public-beta/ enterprises can do this?

[dougsland]

ah looking https://github.blog/changelog/2022-09-01-github-actions-larger-runners-are-now-in-public-beta/ enterprises can do this?

From my understanding, this is only increasing capacity, not CPU flags in their environment. :(

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.