feat: add Linux x86_64 support to the prebuilt archive#20
Open
luispadron wants to merge 4 commits into
Open
Conversation
Refactors build.sh into two phases (build, package) so per-platform builds can run on heterogeneous CI runners (macOS for darwin-arm64, Linux for linux-x86_64) and a final packaging job fans them in. The released tarball now ships per-platform subdirectories of .a / .swiftinterface / .swiftdoc plus a BUILD.bazel that uses select() on (os, cpu) constraints, so a single archive_override works for both macOS and Linux consumers.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Addresses CodeQL / zizmor / Semgrep findings on the workflows: defaults GITHUB_TOKEN to contents:read, opts the publish job into contents:write for gh release create, pins swift-actions/setup-swift to a commit SHA, and hoists workflow_dispatch inputs into env vars in the publish step's run block to avoid shell-context-variable injection.
Three fixes from the first dry-run on the PR: - Linux: rules_swift's local toolchain refuses to configure with the default ubuntu-latest gcc, so install clang and set CC/CXX=clang(++) for the build job. - macOS: querying swift_library + cc_library together via cquery set(...) caused the cc_library outputs to land under ios_sim_arm64. Build and query the swift labels and cc_library deps separately so each gets its native config. - Both: process-substitution swallowed cquery non-zero exits, which is how the Linux dry-run silently produced an empty staging tarball. Capture cquery output into a variable, fail fast on empty results.
Three fixes:
- macOS build.sh: skip cquery output paths that point at the ios_sim_arm64
apple-transition variant of cc_library deps (those weren't built by our
darwin-only `bazel build`, so the cp would fail). Restores the original
-f guard.
- Linux build.sh: drop *TestSupport* targets from the build set. Linux
Foundation (swift-corelibs-foundation) isn't compiled with library
evolution, so any target that imports Foundation fails to compile under
swift.enable_library_evolution. Downstream consumers that need test
support on Linux can build from source.
- Semgrep shell-injection: funnel workflow_dispatch \`inputs.tag\` and
static \`env.SWIFT_SYNTAX_VERSION\` through explicit env vars instead of
expanding \`\${{ ... }}\` directly in the Clone SwiftSyntax shell bodies
of build-publish.yml and dry-run.yml.
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
2 participants
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.
Summary
build.shinto two phases:build(per-platform binary build, run once perTARGET_PLATFORM) andpackage(combines staged platform tarballs into the final release archive).macos-arm64/,linux-x86_64/) of.a/.swiftinterface/.swiftdoc. The generatedBUILD.bazelusesselect()over@platforms//os+@platforms//cpuconfig_settings so a singlearchive_overrideURL works for any consumer.dry-run.ymlandbuild-publish.ymlto fan out to a macOS job + a Linux job, then fan in to a single packaging/publish job. Linux usesswift-actions/setup-swift@v2for the Swift toolchain and pulls a static buildozer release.apple/swift-syntaxcheckout'sBUILD.bazelandutils/bazel/swift_syntax_library.bzlon Linux builds to drop the@build_bazel_rules_appleload +ios_xctestrun_runner/ios_unit_testreferences that the prebuilt doesn't need.Why
Consuming the current prebuilt on a Linux Bazel build fails with
module 'SwiftSyntax' was created for incompatible target arm64-apple-macos13.0, because the.aand.swiftinterfacefiles in the archive are arm64-apple-macos only. Downstream repos that want to run their Bazel build on Blox/Linux runners have had to work around this by skipping thearchive_overrideon Linux. With per-platform artifacts, that workaround can go away.Test plan
dry-runworkflow runs on this PR (validates bothbuild-macos-arm64+build-linux-x86_64jobs and thepackagefan-in step end-to-end).gh workflow run build-publish.ymlagainst a test tag/build-number and verify the published archive'sBUILD.bazelresolves the right artifacts on both macOS and Linux consumers.