Fix release workflow build failures#137
Conversation
Query the Chromium Dashboard for the current stable milestone instead of always targeting latestRelease + 1. Exit with an error if the milestone cannot be determined. Use GITHUB_REPOSITORY env var for GitHub API write calls so the script works on forks as well as upstream.
fd6bfdd to
02f8ed4
Compare
|
Hi @DePasqualeOrg |
stasel
left a comment
There was a problem hiding this comment.
Hi all, apologies it took so long. I finally have some free time to work on this repo and improve it once again. @DePasqualeOrg can you please look at my comment and up the Xcode version to
| # WebRTC milestone branches ship with frozen Chromium buildtools that | ||
| # only support the Xcode/SDK version current at the time of the branch | ||
| # cut. Newer Xcode versions introduce SDK framework splits (e.g. | ||
| # DarwinFoundation, UIUtilities) that break the build. Pin to the | ||
| # version expected by the buildtools (see build/mac_toolchain.py in | ||
| # the WebRTC source for each milestone). | ||
| - name: Select Xcode | ||
| run: sudo xcode-select -s /Applications/Xcode_16.1.app |
There was a problem hiding this comment.
Very annoying we have to manually maintain the Xcode version. But now the latest supported according to mac_toolchain.py is version 26.2. I will merge it as-is and bump the version later
There was a problem hiding this comment.
Also, how can we be sure that the GitHub macOS runner has this version of xcode installed?
| with: | ||
| name: WebRTC.xcframework | ||
| path: src/out/WebRTC.xcframework | ||
| path: src/out/WebRTC-*.xcframework.zip |
There was a problem hiding this comment.
Nice catch - thanks (Not sure how it worked until now)
There was a problem hiding this comment.
Actually, I think it may create a zip inside a zip file and can break something.
|
Hi @DePasqualeOrg |
The weekly release workflow has been failing since late October 2025. There were two independent problems:
1. Release script stuck on outdated milestones
getNextRelease()always targetslatestRelease + 1, so after M141 it kept trying to build M142 every week. M142's buildtools were incompatible with the CI runner, so it failed repeatedly while Chromium stable advanced to M144.The script now queries the Chromium Dashboard
fetch_milestonesAPI for the current stable milestone and skips ahead to it. If the API call fails, the script exits with an error.2. Xcode SDK incompatibility
WebRTC milestone branches ship with frozen Chromium buildtools that only support the Xcode/SDK version current at the time of the branch cut. As GitHub Actions runner images update, newer Xcode versions introduce SDK framework splits (e.g.
DarwinFoundation,UIUtilities) that break the build.Both workflows now pin Xcode 16.1 (the version expected by current buildtools — see
build/mac_toolchain.pyin the WebRTC source). This needs to be updated when future milestones require a newer Xcode. The manual build workflow also uploads the build output as a zip to preserve macOS framework symlinks.Other minor changes:
GITHUB_REPOSITORYenv var for all GitHub API calls instead of hardcodingstasel/WebRTC. This makes the script work when run from forks.X.Y.Zversion instead of onlyX.0.0. Patch releases (e.g.144.0.1) would break the URL update inPackage.swift.Testing
The workflow ran successfully and produced releases of the latest versions on DePasqualeOrg/WebRTC. The x.0.1 patch versions have been patched for the missing header issue mentioned below, so they work on iOS and macOS.
Note: Milestones M141–M144 have a separate issue where framework headers aren't copied into the bundle (webrtc:450130875), which causes build failures in Xcode. CL 424441 fixed this for iOS but not for macOS — the macOS framework is still missing headers as of M145. The upstream fix adds
create_bracket_include_headersas a dependency formac_framework_bundlebut doesn't copy the generated headers into the bundle'sVersions/A/Headers/directory.