@htekdev/actions-debugger 1.0.123 → 1.0.124

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,83 @@
1
+ id: known-unsolved-070
2
+ title: 'ubuntu-24.04 image 20260513.135 breaks WireMock-Spring dynamic port binding in @ConfigurationProperties tests'
3
+ category: known-unsolved
4
+ severity: limitation
5
+ tags:
6
+ - ubuntu
7
+ - ubuntu-24.04
8
+ - spring-boot
9
+ - wiremock
10
+ - configurationproperties
11
+ - regression
12
+ - java
13
+ - test
14
+ patterns:
15
+ - regex: 'foo\.bar\.service\.url=http://localhost:\d+'
16
+ flags: i
17
+ - regex: 'http://localhost:9008'
18
+ flags: i
19
+ - regex: '@ConfigurationProperties'
20
+ flags: i
21
+ - regex: 'wiremock-spring-boot'
22
+ flags: i
23
+ error_messages:
24
+ - 'foo.bar.service.url=http://localhost:<random>'
25
+ - 'The @ConfigurationProperties(prefix = "foo.bar.service") bean ends up bound to the static fallback URL from application-integration-test.yml (http://localhost:9008).'
26
+ - 'The HTTP client then hits localhost:9008 and the test times out.'
27
+ root_cause: |
28
+ Starting with Ubuntu 24.04 image `20260513.135`, some Spring Boot integration tests that rely on
29
+ `wiremock-spring-boot` dynamic port injection regress in GitHub Actions even though the same commit,
30
+ same JDK, and same test pass on `ubuntu-22.04` and on the older Ubuntu 24.04 image `20260413.86`.
31
+
32
+ The observed behavior is:
33
+ 1. WireMock starts and publishes a dynamic property such as `foo.bar.service.url=http://localhost:<port>`.
34
+ 2. The property is visible in logs before the Spring banner.
35
+ 3. The `@ConfigurationProperties` bean still binds to the static fallback value from YAML
36
+ (`http://localhost:9008`).
37
+ 4. The client calls the fallback URL and the test times out.
38
+
39
+ The exact platform-level trigger inside the updated runner image has not been isolated yet. The issue
40
+ is deterministic on the affected image family, reproducible across multiple repositories, and still open.
41
+ At the time of writing there is no confirmed runner-side fix or single root cause from GitHub.
42
+ fix: |
43
+ There is no confirmed upstream fix yet.
44
+
45
+ Current workarounds:
46
+ - pin the workflow to `ubuntu-22.04` while the Ubuntu 24.04 regression is investigated
47
+ - avoid test setups that rely on `@ConfigurationProperties` picking up a dynamically injected URL
48
+ - pass the WireMock URL through `@DynamicPropertySource`, a test-specific bean, or direct
49
+ `Environment` reads closer to the HTTP client wiring
50
+ fix_code:
51
+ - language: yaml
52
+ label: 'Pin the test job to Ubuntu 22.04 until the regression is fixed'
53
+ code: |
54
+ jobs:
55
+ integration-tests:
56
+ runs-on: ubuntu-22.04
57
+ steps:
58
+ - uses: actions/checkout@v4
59
+ - uses: actions/setup-java@v4
60
+ with:
61
+ distribution: temurin
62
+ java-version: '21'
63
+ - name: Run integration tests
64
+ run: ./mvnw test
65
+
66
+ - language: java
67
+ label: 'Inject the dynamic WireMock URL through DynamicPropertySource'
68
+ code: |
69
+ @DynamicPropertySource
70
+ static void registerWireMockProperties(DynamicPropertyRegistry registry) {
71
+ registry.add("foo.bar.service.url", wireMockServer::baseUrl);
72
+ }
73
+ prevention:
74
+ - 'Treat Ubuntu image rollouts as a possible source of Java integration-test regressions, even when your dependencies are unchanged.'
75
+ - 'Prefer explicit test-time property injection over fallback YAML values when the URL must come from a dynamically started mock server.'
76
+ - 'Keep a side-by-side `ubuntu-22.04` control job available when debugging new `ubuntu-latest` regressions.'
77
+ docs:
78
+ - url: 'https://github.com/actions/runner-images/issues/14136'
79
+ label: 'actions/runner-images#14136 — ubuntu-24.04 image 20260513.135 breaks WireMock-Spring dynamic ports'
80
+ - url: 'https://docs.spring.io/spring-framework/reference/testing/testcontext-framework/ctx-management/dynamic-property-sources.html'
81
+ label: 'Spring Docs — @DynamicPropertySource'
82
+ - url: 'https://github.com/wiremock/wiremock-spring-boot'
83
+ label: 'wiremock-spring-boot project'
@@ -0,0 +1,74 @@
1
+ id: runner-environment-224
2
+ title: 'windows-2025-vs2026 UWP builds with PlatformToolset v143 fail with MSB8020'
3
+ category: runner-environment
4
+ severity: error
5
+ tags:
6
+ - windows
7
+ - uwp
8
+ - msvc
9
+ - vs2026
10
+ - v143
11
+ - v145
12
+ - msbuild
13
+ - migration
14
+ patterns:
15
+ - regex: 'MSB8020: The build tools for ''v143'' application Type UWP \(Platform Toolset = ''Visual Studio 2022''\) cannot be found'
16
+ flags: i
17
+ - regex: '<PlatformToolset>v143</PlatformToolset>'
18
+ flags: i
19
+ - regex: 'windows-2025-vs2026'
20
+ flags: i
21
+ error_messages:
22
+ - 'MSBUILD : error MSB8020: The build tools for ''v143'' application Type UWP (Platform Toolset = ''Visual Studio 2022'') cannot be found.'
23
+ - 'The same project builds cleanly on windows-2025 (VS 2022) because v143 is the native toolset there.'
24
+ root_cause: |
25
+ The `windows-2025-vs2026` image is a Visual Studio 2026 image. It ships the VS 2026
26
+ native MSVC toolset (`v145`), but it does NOT include the legacy VS 2022 UWP toolset
27
+ overlay for `PlatformToolset=v143`.
28
+
29
+ Legacy UWP C++ projects often keep `<PlatformToolset>v143</PlatformToolset>` in the
30
+ `.vcxproj` file. That works on `windows-2025` (VS 2022), but when the same workflow is
31
+ moved to `windows-2025-vs2026` — or when `windows-latest` rolls onto the VS 2026 image —
32
+ MSBuild fails at `PrepareForBuild` with MSB8020 before compilation starts.
33
+
34
+ Issue #14101 was later clarified by the reporter: the break is real, but the root cause is
35
+ not a partially missing component. The image is behaving as a VS 2026-only environment, and
36
+ the workflow is still targeting an older UWP toolset that is no longer present there.
37
+ fix: |
38
+ Option 1 — Migrate the project to `PlatformToolset=v145` (recommended on VS 2026 images).
39
+
40
+ Option 2 — If the project must stay on `v143`, pin the workflow to a VS 2022 image such as
41
+ `windows-2025` instead of `windows-2025-vs2026` or `windows-latest`.
42
+
43
+ Option 3 — Isolate legacy UWP builds in a dedicated workflow that stays on VS 2022 while the
44
+ rest of the repository migrates to VS 2026.
45
+ fix_code:
46
+ - language: xml
47
+ label: 'Migrate the project file to the VS 2026 toolset'
48
+ code: |
49
+ <PropertyGroup Label="Configuration">
50
+ <ConfigurationType>StaticLibrary</ConfigurationType>
51
+ <PlatformToolset>v145</PlatformToolset>
52
+ </PropertyGroup>
53
+
54
+ - language: yaml
55
+ label: 'Keep legacy UWP builds on the VS 2022 image'
56
+ code: |
57
+ jobs:
58
+ build-uwp:
59
+ runs-on: windows-2025
60
+ steps:
61
+ - uses: actions/checkout@v4
62
+ - name: Build legacy UWP project
63
+ run: msbuild MyApp.sln /p:Configuration=Release /p:Platform=x64
64
+ prevention:
65
+ - 'Audit Windows workflows for `<PlatformToolset>v143</PlatformToolset>` before moving them to `windows-2025-vs2026` or `windows-latest`.'
66
+ - 'Treat Visual Studio image migrations as toolchain migrations, not just path changes.'
67
+ - 'Pin `runs-on` explicitly for legacy UWP projects until the toolset migration is complete.'
68
+ docs:
69
+ - url: 'https://github.com/actions/runner-images/issues/14101'
70
+ label: 'actions/runner-images#14101 — windows-2025-vs2026 UWP project fails with MSB8020 on v143'
71
+ - url: 'https://github.com/actions/runner-images/issues/14017'
72
+ label: 'actions/runner-images#14017 — Windows 2025 / VS 2026 rollout announcement'
73
+ - url: 'https://learn.microsoft.com/en-us/cpp/build/reference/msbuild-visual-cpp-overview'
74
+ label: 'Microsoft Docs — MSBuild and Visual C++ toolsets'
@@ -0,0 +1,85 @@
1
+ id: runner-environment-225
2
+ title: 'macOS-26 arm runners can miss the iOS 26.1 simulator runtime needed by Xcode 26.1.1'
3
+ category: runner-environment
4
+ severity: error
5
+ tags:
6
+ - macos
7
+ - macos-26
8
+ - arm64
9
+ - xcode
10
+ - simulator
11
+ - ios
12
+ - xcodebuild
13
+ - runner-image
14
+ patterns:
15
+ - regex: 'Unable to find a destination matching the provided destination specifier:'
16
+ flags: i
17
+ - regex: 'iOS 26\.1 is not installed\. Please download and install the platform from Xcode > Settings > Components\.'
18
+ flags: i
19
+ - regex: 'Exit status: 70'
20
+ flags: i
21
+ error_messages:
22
+ - 'xcodebuild: error: Unable to find a destination matching the provided destination specifier:'
23
+ - '{ platform:iOS, id:dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder, name:Any iOS Device, error:iOS 26.1 is not installed. Please download and install the platform from Xcode > Settings > Components. }'
24
+ - 'Exit status: 70'
25
+ root_cause: |
26
+ The macOS 26 arm64 image version `20260520.0098.1` can expose Xcode 26.1.1 without shipping
27
+ the matching iOS 26.1 simulator/runtime components that Apple tooling expects for that Xcode.
28
+
29
+ Workflows that switch to Xcode 26.1.1 and build for iOS hit an immediate xcodebuild destination
30
+ failure because the placeholder device reports `iOS 26.1 is not installed`. The problem is on the
31
+ runner image, not in the project: the requested platform runtime is simply absent from the hosted
32
+ image at execution time.
33
+
34
+ This differs from the later macOS 26 default-Xcode migration entry: here the failure is a missing
35
+ runtime on the selected Xcode/image combination, not a project that needs to unpin from an older
36
+ Xcode.
37
+ fix: |
38
+ Option 1 — Select an Xcode version whose simulator/runtime set is actually present on the image.
39
+
40
+ Option 2 — Use `OS=latest` or another available simulator destination after checking the installed
41
+ runtimes with `xcrun simctl list runtimes`.
42
+
43
+ Option 3 — Wait for the next runner-image rollout that includes the missing iOS 26.1 runtime if the
44
+ project explicitly requires Xcode 26.1.1.
45
+ fix_code:
46
+ - language: yaml
47
+ label: 'Probe runtimes before building and use an installed simulator version'
48
+ code: |
49
+ jobs:
50
+ ios-build:
51
+ runs-on: macos-26-arm64
52
+ steps:
53
+ - uses: actions/checkout@v4
54
+ - name: Show installed runtimes
55
+ run: xcrun simctl list runtimes
56
+ - name: Build with an installed simulator runtime
57
+ run: |
58
+ xcodebuild build \
59
+ -scheme MyApp \
60
+ -destination 'platform=iOS Simulator,OS=latest,name=iPhone 17 Pro'
61
+
62
+ - language: yaml
63
+ label: 'Pin to a different Xcode already supported by the image'
64
+ code: |
65
+ jobs:
66
+ ios-build:
67
+ runs-on: macos-26-arm64
68
+ steps:
69
+ - uses: actions/checkout@v4
70
+ - uses: maxim-lobanov/setup-xcode@v1
71
+ with:
72
+ xcode-version: '26.4.1'
73
+ - name: Build
74
+ run: xcodebuild build -scheme MyApp -destination 'generic/platform=iOS'
75
+ prevention:
76
+ - 'Always dump `xcrun simctl list runtimes` in CI when adopting a new Xcode/image combination.'
77
+ - 'Prefer `OS=latest` unless your workflow truly requires one exact simulator runtime.'
78
+ - 'Pin both the runner label and Xcode version during major Apple platform transitions.'
79
+ docs:
80
+ - url: 'https://github.com/actions/runner-images/issues/14146'
81
+ label: 'actions/runner-images#14146 — macos-26 arm runner missing iOS simulator 26.1'
82
+ - url: 'https://developer.apple.com/documentation/xcode/installing-additional-simulator-runtimes'
83
+ label: 'Apple Docs — Installing additional simulator runtimes'
84
+ - url: 'https://github.com/maxim-lobanov/setup-xcode'
85
+ label: 'maxim-lobanov/setup-xcode action'
@@ -0,0 +1,91 @@
1
+ id: runner-environment-226
2
+ title: '.NET MAUI iOS publish on macOS-26 can fail because Xcode 26.5 lacks the simulator runtime actool expects'
3
+ category: runner-environment
4
+ severity: error
5
+ tags:
6
+ - macos
7
+ - macos-26
8
+ - maui
9
+ - dotnet
10
+ - ios
11
+ - xcode
12
+ - actool
13
+ - runner-image
14
+ patterns:
15
+ - regex: 'No simulator runtime version from \["23B86", "23C54", "23E254a"\] available to use with iphonesimulator SDK version 23F5054d'
16
+ flags: i
17
+ - regex: 'xcrun: error: unable to find utility "actool"'
18
+ flags: i
19
+ - regex: 'This version of \.NET for iOS \(26\.5\.9001\) requires Xcode 26\.5'
20
+ flags: i
21
+ error_messages:
22
+ - 'No simulator runtime version from ["23B86", "23C54", "23E254a"] available to use with iphonesimulator SDK version 23F5054d'
23
+ - 'xcrun: error: unable to find utility "actool"'
24
+ - 'This version of .NET for iOS (26.5.9001) requires Xcode 26.5'
25
+ root_cause: |
26
+ On the early macOS 26 hosted image rollout, users building .NET MAUI iOS apps with
27
+ `Microsoft.iOS.Sdk` 26.5.9001 were forced into an impossible toolchain combination.
28
+
29
+ `Microsoft.iOS.Sdk` 26.5.9001 requires Xcode 26.5, so downgrading to Xcode 26.4.1 is not a valid
30
+ long-term fix. But the Xcode 26.5 paths that were present on the image had two different failure
31
+ modes:
32
+ - selecting `/Applications/Xcode_26.5.app` or `/Applications/Xcode_26.5.0.app` could not resolve
33
+ `actool`
34
+ - selecting `/Applications/Xcode_26.5_beta_2.app` resolved `actool`, but the required simulator
35
+ runtime for SDK `23F5054d` was not installed
36
+
37
+ GitHub later confirmed that the Xcode 26.5 runtime would arrive on the next image update. Until
38
+ that rollout completed, the hosted image simply did not provide a fully working Xcode 26.5 + MAUI
39
+ iOS 26.5.9001 combination.
40
+ fix: |
41
+ There is no complete workflow-only fix when the hosted image is missing the runtime that Xcode and
42
+ the .NET iOS workload require.
43
+
44
+ Current options:
45
+ - wait for the next runner-image rollout that includes the Xcode 26.5 runtime
46
+ - temporarily downgrade the .NET iOS workload to a version compatible with Xcode 26.4.1
47
+ - add a preflight check so the job fails fast with a clear message instead of burning minutes in publish
48
+ fix_code:
49
+ - language: yaml
50
+ label: 'Fail fast if the required Xcode 26.5 simulator runtime is absent'
51
+ code: |
52
+ jobs:
53
+ publish-ios:
54
+ runs-on: macos-26
55
+ steps:
56
+ - uses: actions/checkout@v4
57
+ - name: Check installed runtimes
58
+ run: |
59
+ xcrun simctl list runtimes
60
+ xcodebuild -version
61
+ - name: Guard against missing Xcode 26.5 runtime
62
+ run: |
63
+ xcrun simctl list runtimes | grep '23F5054d' || {
64
+ echo 'Required Xcode 26.5 simulator runtime is missing on this image.'
65
+ exit 1
66
+ }
67
+
68
+ - language: yaml
69
+ label: 'Pin Xcode 26.4.1 while using a matching older iOS workload'
70
+ code: |
71
+ jobs:
72
+ publish-ios:
73
+ runs-on: macos-26
74
+ steps:
75
+ - uses: actions/checkout@v4
76
+ - uses: maxim-lobanov/setup-xcode@v1
77
+ with:
78
+ xcode-version: '26.4.1'
79
+ - name: Publish with a workload version that matches Xcode 26.4.1
80
+ run: dotnet publish -f net9.0-ios -c Release -r ios-arm64
81
+ prevention:
82
+ - 'Check `xcrun simctl list runtimes` whenever you adopt a new Xcode or .NET iOS workload on hosted macOS images.'
83
+ - 'Pin both Xcode and the .NET iOS workload version together during Apple platform transitions.'
84
+ - 'Add a fast runtime preflight before long `dotnet publish` steps so broken image rollouts fail immediately.'
85
+ docs:
86
+ - url: 'https://github.com/actions/runner-images/issues/14128'
87
+ label: 'actions/runner-images#14128 — macOS-26 hosted image missing simulator runtime required by Xcode 26.5'
88
+ - url: 'https://github.com/actions/runner-images/pull/14114'
89
+ label: 'runner-images pull request referenced in the fix confirmation'
90
+ - url: 'https://learn.microsoft.com/en-us/dotnet/maui/ios/deployment/'
91
+ label: 'Microsoft Docs — .NET MAUI iOS deployment'
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@htekdev/actions-debugger",
3
- "version": "1.0.123",
3
+ "version": "1.0.124",
4
4
  "description": "65+ real GitHub Actions errors, queryable by agents. CLI + MCP server + Copilot skills + error database.",
5
5
  "type": "module",
6
6
  "main": "./dist/index.js",