ci: disable the swift Dependabot ecosystem until its image ships Swift 6.4 - #217
Merged
Merged
Conversation
Dependabot's Swift updater resolves inside its own container, and dependabot-core's swift/Dockerfile pins ARG SWIFT_VERSION=6.3.1. Every manifest under Packages/ is swift-tools-version: 6.4, so resolution aborts before reading a dependency: error: 'browsefeaturecore': package 'browsefeaturecore' is using Swift tools version 6.4.0 but the installed version is 6.3.1 This failed weekly from 2026-08-10 to 2026-09-21 — seven runs, no PRs, no notification, because a failed Dependabot run is not a failed check on anything. Lowering the manifests is not available: they use PackageDescription API that predates no earlier toolchain — .iOS(.v26) and .defaultIsolation(MainActor.self) — so 6.3 would not parse them. So the block is commented out verbatim rather than deleted (its comments record why the directory list and the factory group are shaped as they are), and dependabot-swift-watch.yml polls that ARG line weekly and opens an issue when it reaches 6.4. The watch errors rather than reporting no-change if the ARG line moves upstream. Verified: extraction returns 6.3.1 against the live Dockerfile, sort -V ranks 6.10 above 6.4, and actionlint is clean on the new workflow. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013U8tNXdjZpFPUTWpABee5y
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
Dependabot's weekly
swiftrun has failed every week since 2026-08-10 — seven consecutive runs — producing no PRs and no notification. A failed Dependabot run isn't a failed check on anything, so there's no red X anywhere; it's only visible viagh run list.Dependabot resolves Swift packages inside its own container, and
dependabot-core'sswift/DockerfilepinsARG SWIFT_VERSION=6.3.1. All 19 manifests underPackages/areswift-tools-version: 6.4, so resolution aborts before reading a single dependency.Why not just lower the tools version
Not available — and not for a taste reason. The manifests use
PackageDescriptionAPI that doesn't exist before 6.4:.iOS(.v26)as a platformswiftSettings: [.defaultIsolation(MainActor.self)]inBrowseFeatureCoreandSearchFeatureCoreA 6.3 toolchain wouldn't parse them. That would trade a failing updater for a tree that doesn't build.
What this does
Disables the ecosystem, commented out verbatim rather than deleted. The comments on that block are load-bearing — which directories exist only because Factory is
exact-pinned and must move as a group, and whyPlaybackEngineAudioStreamingis listed separately since #122. Re-deriving that later is how thefactorygroup silently stops covering a directory.Adds
dependabot-swift-watch.ymlto close the gap that disabling opens. Factory isexact: "3.3.2"-pinned in seven manifests and AudioStreamingexact: "1.4.4"in an eighth, and nothing watches them now — trading a silent failure for a silent gap would be no improvement. The watch polls thatARG SWIFT_VERSIONline weekly and opens a single issue when it reaches 6.4. Same shape and reasoning as the existingrunner-image-watch.yml; it costs ~15s of free ubuntu time.It errors rather than reporting no-change if the
ARGline ever moves upstream — a watch that quietly stops watching is precisely the failure it exists to prevent.Verification
6.3.1against the live upstreamDockerfile.sort -Vcomparison checked across6.3/6.3.1/6.4/6.4.0/6.5/6.10/7.0/5.9—6.10correctly ranks above6.4.actionlintclean on the new workflow (and on the unmodifiedrunner-image-watch.ymlas a baseline)..github/dependabot.ymlstill parses;github-actionsremains the only active ecosystem.Note: this and
runner-image-watch.ymlare now waiting on the same Swift 6.4 / Xcode 27 transition from different directions. Neither should be closed assuming the other landing settled it.🤖 Generated with Claude Code
https://claude.ai/code/session_013U8tNXdjZpFPUTWpABee5y