Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[beta] Rollup backports #78141

Merged
merged 12 commits into from
Oct 20, 2020
Merged

[beta] Rollup backports #78141

merged 12 commits into from
Oct 20, 2020

Conversation

pietroalbini
Copy link
Member

Cherry-picked:

r? @ghost

pietroalbini and others added 12 commits October 20, 2020 16:06
The format of the tarballs produced by CI is roughly the following:

    {component}-{release}-{target}.{ext}

While on the beta and nightly channels `{release}` is just the channel
name, on the stable channel is either the Rust version or the version of
the component we're shipping:

    cargo-0.47.0-x86_64-unknown-linux-gnu.tar.xz
    clippy-0.0.212-x86_64-unknown-linux-gnu.tar.xz
    llvm-tools-1.46.0-x86_64-unknown-linux-gnu.tar.xz
    miri-0.1.0-x86_64-unknown-linux-gnu.tar.xz
    rls-1.41.0-x86_64-unknown-linux-gnu.tar.xz
    rust-1.46.0-x86_64-unknown-linux-gnu.tar.xz
    ...

This makes it really hard to get the package URL without having access
to the manifest (and there is no manifest on ci-artifacts.rlo), as there
is no consistent version number to use.

This commit addresses the problem by always using the Rust version
number as `{release}` for the stable channel, regardless of the version
number of the component we're shipping. I chose that instead of "stable"
to avoid breaking the URL scheme *that* much.

Rustup should not be affected by this change, as it fetches the URLs
from the manifest. Unfortunately we don't have a way to test other
clients before making a stable release, as this change only affects the
stable channel.
This fixes numbered channel names being created for the nightly channel,
and once the root cause of this rides the trains, for beta.
This commit changes the way build-manifest is invoked, to let it accept
the Rust version directly instead of requiring the path of the Rust
monorepo and letting build-manifest figure out the path on its own.

This allows to run build-manifest without a clone of the monorepo.
This will prevent the tool mistakenly ignoring the variables if they
happen to contain non-utf8 data.
@pietroalbini
Copy link
Member Author

@bors r+ p=10 rollup=never

@bors
Copy link
Contributor

bors commented Oct 20, 2020

📌 Commit 8918415 has been approved by pietroalbini

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 20, 2020
@bors
Copy link
Contributor

bors commented Oct 20, 2020

⌛ Testing commit 8918415 with merge fb94aa5...

@bors
Copy link
Contributor

bors commented Oct 20, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: pietroalbini
Pushing fb94aa5 to beta...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 20, 2020
@bors bors merged commit fb94aa5 into rust-lang:beta Oct 20, 2020
@rustbot rustbot added this to the 1.48.0 milestone Oct 20, 2020
@pietroalbini pietroalbini deleted the beta-rollup branch December 23, 2020 22:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants