Add Windows build workflow

[SimplyDanny]

Resolves #6350.

[SimplyDanny]

@compnerd, @roman-bcny: Anything else to consider for this basic workflow?

[roman-bcny]

Nice! Maybe you could even start with swift test --filter {one_or_more_test_cases} as many tests are already passing

[roman-bcny]

@SimplyDanny this is weird, in the server 2025 I see the same exact log appear 24 or 25 times in those logs with different timestamps, repeatedly with different command lines. No idea what's going on there, looks like some kind of toolchain glitch?.. Wondering if --filter with just one test would work, maybe --skip is messing things up (but I'm just guessing). I'll see if I can repro.

[roman-bcny]

I now see it's just the build step that's failing so test filters aren't relevant. It seems I'm able to get it to run for much longer with --jobs 1 but still looking

[roman-bcny]

@SimplyDanny a few things from my experiments (roman-bcny#1)

1. I had to add this to my test yml, I was getting a crash otherwise:

      - name: Enable long path support
        run: |
          reg add "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled /t REG_DWORD /d 1 /f

2. I had seen crashes just like you're seeing (I believe build fails with a fatal toolchain error, an might succeed if retried), but this run passed as is: https://github.com/roman-bcny/SwiftLint/actions/runs/19828882552/job/56809390338?pr=1
   I think there is a major flakiness issue with the 6.2.1 toolchain - might have to try reduced --jobs and see if that helps. Alternatively, could try a nightly build of the toolchain like that one SwiftFormat is now using for release builds to get static linking.

3. --skip doesn't seem to work for me, I see 0 executed tests. However I was able to run all tests without a filter and a subset of tests with --filter as you can see on that same run https://github.com/roman-bcny/SwiftLint/actions/runs/19828882552/job/56809390338?pr=1

lmk if there is anything I can help with!

[compnerd]

I would recommend against that workaround - the long paths are an issue, and not all users will be able to enable that. We should instead be fixing those scenarios.

[roman-bcny]

Agree, just listed what I noticed.

[SimplyDanny]

Very unclear to me, what causes the failure. One of the first builds in this branch succeeded building at least and I haven't changed anything significant since then.

Another option I might try is to build it with Bazel. This requires #6364 with rules_swift >= 3.4.0 since older versions had a bug.

This also has the benefit of better caching. However, I need to find out whether the static linking would work with it.

Long paths are my favorite issue on Windows. 😅 However, on my test system, the base path is even longer than the one on the GitHub runners. So that might not be the problem.

Thanks for your support, though. That's much appreciated!

[compnerd]

Another option I might try is to build it with Bazel. This requires #6364 with rules_swift >= 3.4.0 since older versions had a bug.

This also has the benefit of better caching. However, I need to find out whether the static linking would work with it.

Static linking should work properly with bazel or CMake. I made sure to properly enable that on Windows for those build systems.

[roman-bcny]

@SimplyDanny seems like bazel isn't trivial, if you want to give the previous version another try it might work better with the dev toolchain and is just a few line change:
roman-bcny@b60e688

(we'll need the dev toolchain for statically linked releases anyways)

[compnerd]

The failure is windows error 206: the filename or extension is too long - interesting. I wonder if using subst might be a good idea here to workaround this.

[compnerd]

This seems to fail similarly 🤔 I think that we might be generating a file with an invalid character? Note that Foundation is long path aware and will protect you against issues due to path length when ever possible.

[roman-bcny]

Latest build seems to be a success! --skip doesn't seem to be working correctly, I had that in my tests too - but --filter did work for me

[SimplyDanny]

I don't want to give up on --skip just yet ... 😅 It works for me locally. It's only that I need to exclude even more tests which also fail with --filter.

Other than that, long file paths seem to be an issue indeed. However, that doesn't seem to be caused by a single source file being too long, but by a generated file in the test process. Because actually, FrameworkTests runs too, even in a combination with other tests. Only running all working tests at the same time fails. So the long path seems to be related to the number of test cases being executed at the same time.

The Bazel build doesn't quite work on Windows. There are still too many issues that require fixes upstream.

[roman-bcny]

@SimplyDanny I'm trying to fix test on #6365 and the remaining issue is with buildkite, seems to be related to /var symlink getting resolved to /private/var on macOS, causing path mismatches so glob tests etc fail, but it might be a pre-existing issue. I see that you have a green build here which is a bit puzzling. Maybe you also ran into /var vs /private/var and somehow this is no longer an issue because of the bazel config tweaks you made?

[SimplyDanny]

@SimplyDanny I'm trying to fix test on #6365 and the remaining issue is with buildkite, seems to be related to /var symlink getting resolved to /private/var on macOS, causing path mismatches so glob tests etc fail, but it might be a pre-existing issue. I see that you have a green build here which is a bit puzzling. Maybe you also ran into /var vs /private/var and somehow this is no longer an issue because of the bazel config tweaks you made?

I don't think it's due to my changes. standardizingPath removes leading /private if the resulting path still exists. Bazel works in /private/var, so this becomes really relevant. The standardization applied ones needs to be applied to all paths that are compared in tests. I did similar in #6342 in ConfigurationTests. I guess that some of the changes made there also need to be applied in your PR because of the other internal changes on paths.

[SimplyDanny]

The workflows basically work now, however, not reliably. Sometimes they still get stuck during compilation (like in the last run).

[roman-bcny]

@SimplyDanny thanks

• anything blocking you from merging Improve performance of excluded files filter #6342?
• anything I can do to help here? I don't think we possess superpowers to stop builds from getting stuck unfortunately but if there's something I can help investigate (like an alternative approach) lmk.

[SimplyDanny]

• anything blocking you from merging Improve performance of excluded files filter #6342?

Just fear. 😅 Every time we try to improve performance in this area, there were some edge cases we didn't have considered and changes had to be reverted. So I want to be really sure this doesn't break anything. But I might merge it shortly and offer a prerelease to let people try.

• anything I can do to help here? I don't think we possess superpowers to stop builds from getting stuck unfortunately but if there's something I can help investigate (like an alternative approach) lmk.

You are right. Let's merge it and observe how it behaves. In parallel, I try to get it building with Bazel for the reasons mentioned above. If we are lucky, it might also be more stable.

[SimplyDanny]

• anything blocking you from merging Improve performance of excluded files filter #6342?

So at least the relevant parts on the testing side got merged. You can now build on them in the other PR.

[roman-bcny]

Thank you!

Ugh, I just ran into the same issue we saw before with builds crashing, on the developer snapshot, so that didn't magically resolve the issue :/

[941/1014] Compiling SwiftLintBuiltInRules VoidReturnRule.swift
Error: Process completed with exit code 1.

https://github.com/realm/SwiftLint/actions/runs/20031956981/job/57443150646?pr=6365

[SimplyDanny]

Ugh, I just ran into the same issue we saw before with builds crashing, on the developer snapshot, so that didn't magically resolve the issue :/

Yeah, both Windows builds fail randomly. It's still good we have them now. However, that will cause many confusions over time. It would be important to get them stable, but I have no idea at the moment what even causes the error.

[roman-bcny]

I poke at a few dev snapshots in my fork and this one didn't crash on me yet so there is hope!
#6371

[roman-bcny]

Ugh spoke too soon. That one doesn't seem to work on ARM. Sad.

[roman-bcny]

Updated to the latest (Dec 1) snapshot and it's green on both x64 and arm! #6371

I'm told there were some issues with arm that are being looked into but Dec 1 was worked around so hopefully it just works.