-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
xtask-unpublished: output a markdown table #12085
Conversation
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
It works! See https://github.com/rust-lang/cargo/actions/runs/4891160691/jobs/8731327847. |
5a0e91b
to
78730a6
Compare
ffa4702
to
01b3f1e
Compare
@bors try |
ci: check if a crate needs a version bump when source files change
💥 Test timed out |
ci/validate-version-bump.sh
Outdated
set -euo pipefail | ||
|
||
# When `BASE_SHA` is missing, we assume it is from bors merge commit, | ||
# so `HEAD~` should find the previous commit on master branch. | ||
base_sha=$(git rev-parse "${BASE_SHA:-HEAD~}") | ||
commit_sha=$(git rev-parse "${COMMIT_SHA:-HEAD}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was assuming this would be written as an xtask, rather than a shell script wrapping one. It'd make it easier to identify changes that way.
These tree packages are considered to be published something. To reduce the logic of xtask-unpubilshed, let's flag them false for now. We can always set it `true` when needed.
01b3f1e
to
f20c9ae
Compare
r? @epage Tweaked it a bit. Thanks for the review! |
f20c9ae
to
8620f5a
Compare
@bors r+ |
This will report what commits affect each publishable package and serves as an alternative to rust-lang#12085. CI can run this as `cargo changes HEAD~ HEAD^2` and that will capture all of the commits within the PR (this is the range I used in `committed`). There is still work needed to integrate this with an action; this is just a rough base-line implementation. I originally tried to use `cargo package --list` to determine what files belong to what packages but that was taking too long for some reason (it works well in `cargo release` for my crates). We can either look into that in the future or do our own heuristics to filter out content.
☀️ Test successful - checks-actions |
Update cargo 10 commits in ac84010322a31f4a581dafe26258aa4ac8dea9cd..569b648b5831ae8a515e90c80843a5287c3304ef 2023-05-02 13:41:16 +0000 to 2023-05-05 15:49:44 +0000 - xtask-unpublished: output a markdown table (rust-lang/cargo#12085) - fix: hack around `libsysroot` instead of `libtest` (rust-lang/cargo#12088) - Optimize usage under rustup. (rust-lang/cargo#11917) - Update lock to normalize `home` dep (rust-lang/cargo#12084) - fix: doc-test failures (rust-lang/cargo#12055) - feat(cargo-metadata): add `workspace_default_members` (rust-lang/cargo#11978) - doc: clarify implications of `cargo-yank` (rust-lang/cargo#11862) - chore: Use `[workspace.dependencies]` (rust-lang/cargo#12057) - support for shallow clones and fetches with `gitoxide` (rust-lang/cargo#11840) - Build by PackageIdSpec, not name, to avoid ambiguity (rust-lang/cargo#12015) r? `@ghost`
What does this PR try to resolve?
Part of #12033
The purpose of these changes is to make sure that every subcrate gets a version bump if their source files change.This turns out to be adding a table output for xtask-unpublished. Will address CI issue later on.
How should we test and review this PR?
This extends
xtask-unpublished
to--package
flagThis also marks
capture
cargo-test-support
, andcargo-test-marco
crates aspublish = false
.To review, you may want to
cargo unpublished
and check the output correctness.Additional information
Initially, I was going to run
gh pr comment --body <comment>
to write a comment on the pull request. I had a basic example here. However, it seems to have some safety concerns 1 — we may grant too many permissions to a malicious PR author to mess up our pull requests.I stopped to provide this new CI job only. No any new GitHub Action permission required.
If you got a good idea to post a comment without sacrificing CI security and complexity, I am happy to know!
Footnotes
https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ ↩