Hello!
I currently have a working CI pipeline on linux using GitLab-hosted runner for my private repo. When I add WIndows or MacOS tags, then the pipeline gets stuck - it appears that shared runners for these operating systems are not available. Yet it says here that there is Beta support for them.
Here is a snippet from my yaml build file. If I add the windows tag then it stalls.
build:
stage: build
script:
- 'cmake --build . --config $BUILD_TYPE'
artifacts:
paths:
- $CI_PROJECT_DIR/build/
- $DATA_ROOT
tags:
- linux
I just want to confirm that this is correct - thank you.
According to the docs, Windows is in Beta for all tiers, macOS is in Beta for Premium/Ultimate tiers.
Also, Windows Shared Runners on GitLab.com SaaS moved to Server 2022, and deprecated older tags.
I do not see a windows tag though, only shared-windows (deprecated) and the newer tag saas-windows-medium-amd64 which you will want to use in your jobs. 
The changes are also noted for breaking changes in 17.0 in May in this blog post
Can you share a screenshot of your pipeline view for the specific jobs, and the job log view? I’m curious whether the jobs are not picked up, or any other error occurs.
Thanks! I tried using the windows tag saas-windows-medium-amd64. If I have both that tag and the linux tag then the build gets stuck, but if I only have the windows tag, then it appears to work.
By the way, does this windows image have MSVC compiler installed ? I will need that.
There is no generic linux tag for GitLab.com shared Runners, so maybe that is the problem here. All supported tags are listed in Hosted runners on Linux | GitLab
linux as runner tag would work, if you install and host your own runner that supports the tag to pickup jobs.
It is linked from the docs, cookbooks/preinstalled-software/README.md · main · GitLab.org / Ops Sub-Department / shared-runners / images / gcp / windows-containers · GitLab MSVC is covered through C++ build tools. You also get CMake pre-installed, which is a common option for build frameworks for cross-platform builds.
1 Like
@dnsmichi the pipeline gets stuck if I have two tags, one for windows and one for linux. Is this by design, or a bug ? Single tag build will work for both windows and linux.
tags:
- saas-linux-medium-amd64
- saas-windows-medium-amd64
Good question, I needed to search the documentation. According to A runner and a job have multiple tags, the following scenario comes into play:
- The Runner is configured with
[saas-linux-medium-amd64]
- The job has the tags
[saas-linux-medium-amd64, saas-windows-medium-amd64]
Since not all tags match for the job, the Runner does not pick up the job. So this is by design.
I understand the desire to have a generic build job for multiple platforms, but to solve the tagging problem, I recommend splitting the jobs accordingly. You can use job templates with extends to not reinvent the wheel. For example:
.build-tmpl:
stage: build
script:
- 'cmake --build . --config $BUILD_TYPE'
artifacts:
paths:
- $CI_PROJECT_DIR/build/
- $DATA_ROOT
build-windows:
extends: [.build-tmpl]
tags: [saas-windows-medium-amd64]
build-linux:
extends: [.build-tmpl]
tags: [saas-linux-medium-amd64]
Quick test in SaaS Runners Linux Windows Tags test (!28) · Merge requests · Michael Friedrich / ci-cd-playground · GitLab
The builds are expected to fail, I do not have any source code to build in the repository. The Linux build also uses the default image, where cmake is not installed.
1 Like
Great, thank you! That works. Thank you for your help, much appreciated.
1 Like
@dnsmichi one more question Windows PowerShell and Linux bash use different syntax.
What is the recommended way of scripting for both PS and bash ? I want to hopefully reuse the same script for both environments. Or, it would helpful to specify use of bash on Windows, in .gitlab-ci.yaml
I don’t know if that is possible. In an OSS project in 2018ish, we built the project with shell scripts, and Powershell scripts separately. The syntax was too different. AFAIK you can run Powershell scripts on Linux too, but it might not work as intended.
My gut feeling is - start with the Linux build scripts, then mimic the same steps for the Powershell Windows scripts. Refactor the code to be generic with functions, and make the scripts parametrizable - i.e. through environment variables that work for both platforms.
1 Like
Thanks. As Windows support is in beta, you guys might consider supporting another shell on windows - this is currently possible on github and it make life a lot easier. Anyways, this is off topic - thanks again !!
