Does not work with toolset 14.28 on `windows-latest`

[intjelic]

And in general, why not using the latest version of msvc in the README.md then show how to use older versions.

workflow file

    runs-on: windows-latest

    steps:
      - uses: ilammy/msvc-dev-cmd@v1
        with:
          arch: amd64
          toolset: 14.28

output

Run ilammy/msvc-dev-cmd@v1
Found with vswhere: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvarsall.bat
Error: Could not setup Developer Command Prompt: invalid parameters
[ERROR:vcvars.bat] Toolset directory for version '14.28' was not found.
[ERROR:VsDevCmd.bat] *** VsDevCmd.bat encountered errors. Environment may be incomplete and/or incorrect. ***
[ERROR:VsDevCmd.bat] In an uninitialized command prompt, please 'set VSCMD_DEBUG=[value]' and then re-run
[ERROR:VsDevCmd.bat] vsdevcmd.bat [args] for additional details.
[ERROR:VsDevCmd.bat] Where [value] is:
[ERROR:VsDevCmd.bat]    1 : basic debug logging
[ERROR:VsDevCmd.bat]    2 : detailed debug logging
[ERROR:VsDevCmd.bat]    3 : trace level logging. Redirection of output to a file when using this level is recommended.
[ERROR:VsDevCmd.bat] Example: set VSCMD_DEBUG=3
[ERROR:VsDevCmd.bat]          vsdevcmd.bat > vsdevcmd.trace.txt 2>&1

[pzhlkj6612]

Hi. I've tried this configuration and it works well. Could you please try to enable step debug logging, re-run the workflow and paste the output here?

[intjelic]

I can't retry with enable step debug logging with this repo unfortunately. That said, I tried to reproduce the error on a new repo with a quasi-identical workflow, and it is working fine. Like you said.

The initial (failing) workflow file was exactly that.

name: Windows

on:
  push:
    branches: [master]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  python:
    strategy:
      matrix:
        # config: [X64] # TODO; add 'Win32', 'ARM' and 'ARM64' later
        arch: [amd64]
        build_type: [release, debug]

    runs-on: windows-latest

    steps:
      - uses: ilammy/msvc-dev-cmd@v1
        with:
          arch: ${{ matrix.arch }}
          toolset: 14.28

      - uses: actions/checkout@v2

      - name: Add platform-specific files
        run: cp src/platforms/windows/pyconfig.h include

      - name: Compile Python source files
        run: |
          mkdir -p build
          cd build
          cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=${{ matrix.build_type }} ..
          nmake

And I tried reproducing with this file.

name: Windows

on:
  push:
    branches: [master]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  debug:
    strategy:
      matrix:
        arch: [amd64]
    runs-on: windows-latest
    steps:
      - uses: ilammy/msvc-dev-cmd@v1
        with:
          arch: ${{ matrix.arch }}
          toolset: 14.28

      - run: Write-Output "Hello world!";

I moved to egor-tensin/vs-shell@v2 for the time being (it fixed the issue) but I'll try again with this action later as I need the arch-related feature provided by this action.

I'd close this issue for now.

[ilammy]

That said, I tried to reproduce the error on a new repo with a quasi-identical workflow, and it is working fine.

This might be caused by some action runner shenanigans. windows-latest might mean slightly different environments, they upgraded on per-repo basis. But it seems that 14.28 should be included in all versions that they ship. See actions/virtual-enviroments.

One thing to note is that neither this action, nor egor-tensin/vs-shell are installing MSVC components. They merely set up the environment for tools that are already installed in the system. If the tools are no there then they're not there. For example, if you're using private action runners, then that's the administrator's responsibility to install all the components.

Comparing the environments might shed some light onto this. The first step “Set up job” will output details:

Current runner version: '2.278.0'
Operating System
  Microsoft Windows Server 2019
  10.0.17763
  Datacenter
Virtual Environment
  Environment: windows-2019
  Version: 20210516.0
  Included Software: https://github.com/actions/virtual-environments/blob/win19/20210516.0/images/win/Windows2019-Readme.md
  Image Release: https://github.com/actions/virtual-environments/releases/tag/win19%2F20210516.0

If both workflows use exactly the save environment version but one fails while other does not – that's weird. However, if a failing one has a different environment, that might be the reason.

[pzhlkj6612]

windows-latest might mean slightly different environments, they upgraded on per-repo basis.

Hi @ilammy . I want to know why you said "they upgraded on per-repo basis". IIRC, for GHA runners, the latest image of the selected OS will be fetched when each workflow starts running, no matter which repository.

[ilammy]

I want to know why you said "they upgraded on per-repo basis".

That just seemed to me that they might be doing it. I've seen with ubuntu-latest mean one Ubuntu version in a fork, a different – older one in the parent repo. After some time the parent repo has updated to the same distro version, but a different – now newer image when compared to the fork. Eventually they got is sync though.

No idea if that was a one-off thing, I'm not tracking it too closely. But I would not be surprised if a newly created repo would run something different from an existing one.

[intjelic]

Thanks for the valuable info (as I'm not familiar with dev on Windows). I'll look into this when the moment is right for the development of the project.

That just seemed to me that they might be doing it. I've seen with ubuntu-latest mean one Ubuntu version in a fork, a different – older one in the parent repo. After some time the parent repo has updated to the same distro version, but a different – now newer image when compared to the fork. Eventually they got is sync though.

I would not be surprised too. What they might just do is have per Azure region database with their images for runners, which might not always be in sync, then depending on the location of runner picking the job, you would get those small temporary differences.

[pzhlkj6612]

Oh, thank you guys for sharing. I didn't know this before.