Conversation
…branch For a tag build it asks for the branches whose tip the commit is, in one call where which-branch compared the commit with every branch in turn, and finds the branch's pull request by owner:branch: given a bare branch name GitHub ignores the filter and lists every open pull request, and which-branch took whichever matched first. The release notes are passed under a delimiter they cannot contain, where a line reading EOF ended them. No Python, and no PyGithub to install. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… own, as Windows is The hosted build signed nothing on macOS: the install rules left signing to a packaging job that was never enabled, so the disk image carried an unsealed bundle. Now the build job archives the stripped bundle beside its package.env, and sign-and-package-mac signs it inside out with ViewerCodeSign.cmake, has vpk add its updater, seal, notarize and staple it, and builds the disk image from that bundle with dmgbuild, so a viewer installed from the image updates itself; then signs, notarizes and staples the image. The Windows job signs every binary, Setup.exe and Update.exe through AzureSignTool and a certificate in Azure Key Vault, in place of viewer-build-util's sign-pkg-windows. Pull requests, and builds without the secrets, are packaged unsigned. The install step signs on the hosted build too, ad-hoc, and the package step seals the bundle again once it has stripped the executable, which left every local disk image with a broken signature. Data files are no longer signed: their signatures live in extended attributes that update packages drop. VLC's plugins.dat is not shipped on macOS, being the one data file in a code directory, and stale once the plugins are signed. The disk image is APFS, ULMO: HFS+ decomposed the names of the font stand-ins with Japanese names and broke the seal. Linden's Second Life background and layout, the altool notarization script and the AppleScript helpers go. AL_ENABLE_SIGNING, which nothing read, is retired; the identity alone decides, and AL_NOTARY_PROFILE notarizes the velopack target's package. package.env has one set of keys for both platforms, and macOS has its Velopack channel, osx-arm64 or osx-x64. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…se them scripts/signing/macos_signing_secrets.py takes the Developer ID Application .p12 exported from Keychain Access and the App Store Connect API key's .p8. It imports the certificate into a keychain of its own, as the build does, and wants one private key and one identity macOS trusts for code signing; it encrypts it again under a password it makes, in the format the build's `security import` reads, which LibreSSL's AES output is not; and it tries the API key against the notary service. Then it stores the secrets with `gh secret set`, or writes them to private files. No password goes on a command line: openssl reads them through pipes, and gh reads each value on its standard input. An individual API key must be given no issuer ID, so the build passes one only when MACOS_NOTARY_ISSUER_ID is set, and the script removes a stale one when it stores an individual key. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ves its disk to the viewer vcpkg builds the ports with the CMake on the path and hashes its version into every package ABI. Linux pinned it; macOS and Windows took whatever PyPI had, so CMake 4.4.4 turned every package into a cache miss there: macOS built 154 ports from source (37 minutes, and the disk the viewer's macOS row then ran out of), Windows spent 86 minutes on what took one the day before. CMake and Ninja are pinned on every runner now, 4.4.3 where Linux's floor will not do, which is what the cache holds. What the jobs keep on disk shrinks too: no local binary cache, which nothing on a one-job runner reads again; each port's sources, build tree and staged package removed once installed; CPack's copy of the tree removed once archived; and on macOS the Xcodes the build does not use and the Android SDK removed in the background while the ports build. Every row reports the disk it finished with. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…chives
The symbol setup was made for a crash service that wanted an archive per
platform: a tarball of the viewer's PDB, a zip of the viewer's dSYM, a
tarball of the viewer's split debug file, each uploaded as an artifact and
read by nothing. Sentry was then pointed at the build tree around them,
which on macOS meant it found the dSYM twice, unpacked the zip's copy to a
temporary file, and ran the runner out of disk. Only the viewer had its
debug information kept; the plugins, the CEF hosts and every library
shipped without it.
The `symbols` target now makes a store from the staged tree, using the
staging install's manifest as the list of what ships (the viewer itself,
which the install finds already in place and so leaves out of it, is
named separately). Every binary goes in, with its debug information
beside it where it has any:
Windows the executables and DLLs, each with the PDB its CodeView record
names, or the vcpkg PDB of that name for a prebuilt library
macOS the Mach-O files, each with a dSYM where it has a debug map
Linux filed by build ID, as gdb, debuginfod and distribution debug
packages lay one out: the binary without its debug information
and its .debug, with the sections compressed with zstd (zlib
where objcopy has no zstd)
Binaries are hard links on Windows and macOS, so the store costs only the
debug files. The hosted build makes the store and uploads it, and nothing
else, to Sentry; the archives, their artifacts and the dSYM step after
every macOS link are gone.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… job The Windows rows configure with the ninja presets instead of Visual Studio, naming cl as the compiler. The build tree already supports a Developer Command Prompt: the triplet guess reads VSCMD_ARG_TGT_ARCH and the target architecture is the compiler's. scripts/ci/msvc_environment.py gives the job that prompt's environment: it runs vcvarsall.bat for the runner's architecture under Visual Studio 2026, the one the generator used, and passes on what it changed through GITHUB_ENV and GITHUB_PATH. It leaves out Visual Studio's own CMake and Ninja, which would shadow the pinned ones every vcpkg package ABI hashes, and VCPKG_ROOT, which names Visual Studio's vcpkg rather than the submodule. setup-build runs it when asked; CodeQL's Windows row stays on the Visual Studio generator. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
github-actions
Bot
added
cmake
github_actions
Contributor
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
⛔ Files ignored due to path filters (1)
📒 Files selected for processing (27)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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
1 participant
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.
Description
Related Issues
Issue Link:
Checklist
Please ensure the following before requesting review:
Additional Notes