-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
ci: ensure all tool maintainers are assignable on issues #64119
ci: ensure all tool maintainers are assignable on issues #64119
Conversation
We can't merge this yet as CI will fail due to these errors:
|
784e335
to
ff09ffb
Compare
For everyone pinged by this comment: toolstate is configured to open a new issue when a tool breaks, assigning the people who usually fix those breakages. Unfortunately GitHub only allows assigning people with explicit access to a repo, so we need to grant everyone who's going to be assigned access to the repo. We're going to grant "read" access to the repo, which doesn't add new real permissions (well, it's a public repository...) while allowing y'all to be assigned. Since adding permissions to individuals is not a good practice we should get GitHub teams in the rust-lang org for each tool and then grant access to those teams. Opened PRs in the team repo to synchronize wg-rustfmt and rust-by-example with GitHub. @nikomatsakis which teams should @mark-i-m and @amanjeev be part of for rustc-guide? @therealprof could you put the people responsible for the embedded book in a separate team/wg on the team repo? Then we can automatically synchronize that team with the rust-lang GitHub organization. |
@pietroalbini The @rust-embedded/resources team is responsible for managing the book, is that granular enough for this purpose? |
@therealprof yeah, but it needs to be on the |
Hopefully this satisfies the requirements of rust-lang/rust#64119 Signed-off-by: Daniel Egger <daniel@eggers-club.de>
@pietroalbini Like rust-lang/team#107 ? |
Hopefully this satisfies the requirements of rust-lang/rust#64119 Signed-off-by: Daniel Egger <daniel@eggers-club.de>
Yep! rustfmt and embedded-book should now be fixed. |
@kennytm addressed review comments. |
r=me after everyone is confirmed assignable. |
Also removed
|
GitHub only allows people explicitly listed as collaborators on the repository or who commented on the issue/PR to be assignees, failing to create the issue if non-assignable people are assigned. This adds an extra check on CI to make sure all the people listed as tool maintainers can be assigned to toolstate issues. The check won't be executed on PR builds due to the lack of a valid token.
They don't contribute to rust-by-example anymore.
All the permissions are properly configured 🎉 @bors r=kennytm |
📌 Commit feab38070777e55b4f4fa76c383aa3274b1e1200 has been approved by |
feab380
to
ce451b9
Compare
@bors r=kennytm |
📌 Commit ce451b9 has been approved by |
…ntainers, r=kennytm ci: ensure all tool maintainers are assignable on issues GitHub only allows people explicitly listed as collaborators on the repository or who commented on the issue/PR to be assignees, failing to create the issue if non-assignable people are assigned. This adds an extra check on CI to make sure all the people listed as tool maintainers can be assigned to toolstate issues. The check won't be executed on PR builds due to the lack of a valid token. r? @kennytm
Rollup of 10 pull requests Successful merges: - #63955 (Make sure interned constants are immutable) - #64028 (Stabilize `Vec::new` and `String::new` as `const fn`s) - #64119 (ci: ensure all tool maintainers are assignable on issues) - #64444 (fix building libstd without backtrace feature) - #64446 (Fix build script sanitizer check.) - #64451 (when Miri tests are not passing, do not add Miri component) - #64467 (Hide diagnostics emitted during --cfg parsing) - #64497 (Don't print the "total" `-Ztime-passes` output if `--prints=...` is also given) - #64499 (Use `Symbol` in two more functions.) - #64504 (use println!() instead of println!("")) Failed merges: r? @ghost
GitHub only allows people explicitly listed as collaborators on the repository or who commented on the issue/PR to be assignees, failing to create the issue if non-assignable people are assigned.
This adds an extra check on CI to make sure all the people listed as tool maintainers can be assigned to toolstate issues. The check won't be executed on PR builds due to the lack of a valid token.
r? @kennytm