Skip to content

ci: make musl.sh look for patches next to the script - #163120

Open
lambdageek wants to merge 1 commit into
rust-lang:mainfrom
lambdageek:dont-hardcode-docker-layout
Open

lambdageek wants to merge 1 commit into
rust-lang:mainfrom
lambdageek:dont-hardcode-docker-layout

Conversation

@lambdageek

@lambdageek lambdageek commented Sep 21, 2026 •

Copy link
Copy Markdown
Contributor

Instead of hardcoding the container layout assuming that the local patches are in /build, look for them next to the script. This helps downstream distros to run this script if their container layout is different and they don't put the musl working dir in /build.

This might be an unexpected change for some downstream distros that were using this script from another directory,but arranged for the patches to still be in /build

Instead of hardcoding the container layout assuming that the local
patches are in /build, look for them next to the script.  This helps
downstream distros to run this script if their container layout is
different and they don't put the musl working dir in /build.

This might be an unexpected change for some dowstream distros that
were using this script from another directory,but arranged for the
patches to still be in `/build`
@rustbot rustbot added A-CI Area: Our Github Actions CI A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. labels Sep 21, 2026
@rustbot

rustbot commented Sep 21, 2026

Copy link
Copy Markdown
Collaborator

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: infra-ci
  • infra-ci expanded to Kobzol, Mark-Simulacrum, jieyouxu, marcoieni, ubiratansoares
  • Random selection from Mark-Simulacrum, jieyouxu, marcoieni, ubiratansoares

@Mark-Simulacrum

Copy link
Copy Markdown
Member

Hm, can you say a bit more about what your(?) distro is doing here? I would have somewhat expected that most / all distros want to use their own musl rather than whatever Rust happened to package (we're not necessarily amazing at staying up to date...).

If I'm reading the code right it seems pretty harmless to land this though.

@lambdageek

Copy link
Copy Markdown
Contributor Author

Hm, can you say a bit more about what your(?) distro is doing here?

Context: we distribute in-house builds of the Rust toolchain for teams inside Microsoft (see blog - although that post is mostly talking about the special things we're doing on Windows, but we do also build Linux host tools and target several platforms using the normal cg_llvm backend)

For some targets, we build musl. When we build musl, we're building it in a step in an Azure Pipelines job, not in a Docker container like the ones upstream has defined, so we don't have an analog of these COPY steps:

COPY scripts/musl.sh /build
COPY scripts/musl-cve-2026-6042.diff /build/
COPY scripts/musl-cve-2026-40200.diff /build/

We don't have a /build directory. I think the script and patches for us are in something like /s/.../src/ci/docker/scripts/musl.sh. So because musl.sh currently hardcodes /build/ to find those .patch files, we either need to make our environment more like upstream's (possible), or make the script less sensitive find the patches in a way where it doesn't matter where they all are as long as its all the same directory (preferred).

I would have somewhat expected that most / all distros want to use their own musl rather than whatever Rust happened to package (we're not necessarily amazing at staying up to date...).

The paved path for our internal Linux customers steers them to x86_64-unknown-linux-gnu (AzureLinux 3 and 4). There's just not that many who need musl, and we've not had a reason to get out of sync from upstream Rust packaging here.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-CI Area: Our Github Actions CI A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants