-
Notifications
You must be signed in to change notification settings - Fork 2.6k
xtask-unpublished: output a markdown table #12085
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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/ ↩