should we pin to a rustc nightly version inside the repo? #5561
Labels
A-infra
Area: CI issues and issues that require full access for GitHub/CI
C-question
Category: Questions
S-needs-discussion
Status: Needs further discussion before merging or work can be started
Comments
matthiaskrgr
added
C-question
|
+1 for pinning a nightly
I hope a
We should put a policy in place, that every sync should bump the pinned nightly version to the latest nightly. This policy should be enforced by a GHA somehow (Maybe with a check in
Once we pinned a nightly, we won't be forced to update the nightly version. A policy of no changes in the rust-lang/rust clippy subtree in the no-toolstate-breakage week may be good. But this has to be accepted by the infra team and is not our decision. We should definitely always get a sync in the no-toolstate-breakage week in the rust repo, if this should be problematic, we can ask for that policy to be implemented. As long as we still use rustc master that won't be a problem. For every step here, I would suggest that we do a few syncs to get familiar with the new workflow and then move on with automation/pinning nightlies/... |
I think as long as all commands are executed from the rustc repo root, everything will be fine. The toolchain file is only active for the directory it is in and its subdirectories. (https://github.com/rust-lang/rustup#override-precedence) |
|
I tried to get this to work but hit a wall because clippy requires the |
A somehow dirty hack is to call rustup from the |
|
Good news, rust-lang/rustup#2350 has been closed so this will become unblocked after the next rustup release! 🎉 |
bors
added a commit
that referenced
this issue
Dec 9, 2020
📌 Pin Clippy to a nightly 📌 changelog: none Addresses partially #5561. As proposed there in [this comment](#5561 (comment)), this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling. Open questions: * When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that. * When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful. * Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for `@flip1995` who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas? * I'm not sure if this affects the release process in any way. * ??? `@rust-lang/clippy` thoughts? r? `@flip1995`
bors
added a commit
that referenced
this issue
Dec 9, 2020
📌 Pin Clippy to a nightly 📌 changelog: none Addresses partially #5561. As proposed there in [this comment](#5561 (comment)), this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling. Open questions: * When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that. * When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful. * Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for `@flip1995` who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas? * I'm not sure if this affects the release process in any way. * ??? `@rust-lang/clippy` thoughts? r? `@flip1995`
bors
added a commit
that referenced
this issue
Dec 9, 2020
📌 Pin Clippy to a nightly 📌 changelog: none Addresses partially #5561. As proposed there in [this comment](#5561 (comment)), this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling. Open questions: * When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that. * When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful. * Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for `@flip1995` who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas? * I'm not sure if this affects the release process in any way. * ??? `@rust-lang/clippy` thoughts? r? `@flip1995`
bors
added a commit
that referenced
this issue
Dec 9, 2020
📌 Pin Clippy to a nightly 📌 changelog: none Addresses partially #5561. As proposed there in [this comment](#5561 (comment)), this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling. Open questions: * When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that. * When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful. * Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for `@flip1995` who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas? * I'm not sure if this affects the release process in any way. * ??? `@rust-lang/clippy` thoughts? r? `@flip1995`
bors
added a commit
that referenced
this issue
Dec 10, 2020
📌 Pin Clippy to a nightly 📌 changelog: none Addresses partially #5561. As proposed there in [this comment](#5561 (comment)), this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling. Open questions: * When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that. * When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful. * Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for `@flip1995` who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas? * I'm not sure if this affects the release process in any way. * ??? `@rust-lang/clippy` thoughts? r? `@flip1995`
bors
added a commit
that referenced
this issue
Dec 10, 2020
📌 Pin Clippy to a nightly 📌 changelog: Pin Clippy to a specific nightly version (No more master/custom toolchain required to compile Clippy) Addresses partially #5561. As proposed there in [this comment](#5561 (comment)), this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling. Open questions: * When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that. * When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful. * Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for `@flip1995` who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas? * I'm not sure if this affects the release process in any way. * ??? `@rust-lang/clippy` thoughts? r? `@flip1995`
bors
added a commit
that referenced
this issue
Dec 10, 2020
📌 Pin Clippy to a nightly 📌 changelog: Pin Clippy to a specific nightly version (No more master/custom toolchain required to compile Clippy) Addresses partially #5561. As proposed there in [this comment](#5561 (comment)), this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling. Open questions: * When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that. * When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful. * Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for `@flip1995` who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas? * I'm not sure if this affects the release process in any way. * ??? `@rust-lang/clippy` thoughts? r? `@flip1995`
bors
added a commit
that referenced
this issue
Dec 10, 2020
📌 Pin Clippy to a nightly 📌 changelog: Pin Clippy to a specific nightly version (No more master/custom toolchain required to compile Clippy) Addresses partially #5561. As proposed there in [this comment](#5561 (comment)), this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling. Open questions: * When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that. * When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful. * Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for `@flip1995` who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas? * I'm not sure if this affects the release process in any way. * ??? `@rust-lang/clippy` thoughts? r? `@flip1995`
bors
added a commit
that referenced
this issue
Dec 11, 2020
📌 Pin Clippy to a nightly 📌 changelog: Pin Clippy to a specific nightly version (No more master/custom toolchain required to compile Clippy) Addresses partially #5561. As proposed there in [this comment](#5561 (comment)), this kicks off the process, to help us get acquainted with how the syncs should work, before working on improving the tooling. Open questions: * When performing a rustup, we will need to exclude the commits that were merged that same day, or else wait until that nightly is released. I did not update the documentation about this part, mainly because I'm not sure about how to do that. * When should we perform the rustups now? My first idea is to do it at the same time we do the clippyups, to have a clear cadence and to avoid the two copies of the repo to diverge enough to make the process painful. * Who does the rustups now? If we follow my previous idea and do both rustup and clippyup at the same time, it would be more work for `@flip1995` who currently does the clippyups. I would prefer to establish some kind of rotation to spead the work. Other ideas? * I'm not sure if this affects the release process in any way. * ??? `@rust-lang/clippy` thoughts? r? `@flip1995`
|
I guess it's working fine :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Now that clippy should no longer break since it receives rustc-fixes automatically, do we still need to use the rustc master toolchain?
I wonder if we could use a
rust-toolchainfile to pin clippy to a certain nightly version inside this repo.This could make sure that clippy always compiles for people adding new lints and we might no longer require the rustc master toolchain to build it, the correct nightly would be installed automatically.
If someone merges changes done in the rustc repo down to this clippy repo and resolves the merge conflicts, the nightly version would be bumped to that nightly.
However I am not sure how a
rustc-toolchainfile will behave if it is found inside a subdir of the rustc repo...Also this might introduce a 24 hour delay if we need to wait for a new nightly to be released in some cases (might happen around releases? I don't know). :/
The text was updated successfully, but these errors were encountered: