-
Notifications
You must be signed in to change notification settings - Fork 410
Check each commit at least builds in CI #696
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
Check each commit at least builds in CI #696
Conversation
7870e1c
to
bd44fdb
Compare
.github/workflows/build.yml
Outdated
git rebase upstream/main | ||
- name: For each commit, run cargo check (including in fuzz) | ||
run: | | ||
for COMMITHASH in `git log --format=format:%H upstream/main...HEAD`; do |
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.
Can this be a shell script that devs can run locally, too? Makes it easier to test as well.
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.
A bit more complicated to scan the remotes, but, done!
559b10a
to
8434d06
Compare
Codecov Report
@@ Coverage Diff @@
## main #696 +/- ##
==========================================
- Coverage 91.92% 91.87% -0.05%
==========================================
Files 35 35
Lines 20082 20082
==========================================
- Hits 18461 18451 -10
- Misses 1621 1631 +10
Continue to review full report at Codecov.
|
392c12c
to
8ad9d42
Compare
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.
Added my feedback about how to make this a bit cleaner from a dev point of view. I have a bash alias that sort of does these things so I had some preexisting thoughts on what this might look like longer term.
@@ -0,0 +1,24 @@ | |||
#!/bin/sh |
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.
Here are the use cases as I see them:
As a developer, I want to know that every patch in my stack builds and passes "all?" tests against some remote before I push to my branch so I don't waste time later and have to backtrack when CI finally catches up to tell me I made a mistake.
As a CI tool, I want to verify every commit against main and throw an error if a single commit doesn't build so future rebase and git bisect can work cleanly.
From a developer point of view, I would love to use this tool against my own upstream branches for dependant PRs and in cases where my branch might not be in the most hygienic state, but I still get a lot of value in making sure everything builds with the current state of the world.
I also don't really want rebase done for me since I would like to control when those actions happen in the event I am in a non-clean state.
What about an API like this that allows the users to control the remotes that are used? Makes the auto-complete go away, too.
CI:
Make sure all commits pass against main. I'm not sure the CI context w.r.t. remotes available, but this is the idea.
check-each-commit.sh main
Dev:
As a dev I want to see if my current work in progress is clean against origin
check-each-commit.sh origin/main
As a dev I want to see if my current work in progress is clean against a dependant branch
check-each-commit.sh origin/pre-existing-dependant-branch
As a dev I want to see if my current work in progress is clean against upstream/main and ready for PR.
git rebase upstream/main
- manual
check-each-commit.sh upstream/main
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.
Hmm, I suppose we could just always do a git log
from a given point, but the script as-is doesn't rebase for you, it just makes sure you're built directly on top of upstream/main.
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.
Errr, ok, it wasn't supposed to.
ci/check-each-commit.sh
Outdated
git rebase $UPSTREAM/main | ||
for COMMITHASH in `git log --format=format:%H $UPSTREAM/main...HEAD`; do | ||
git checkout $COMMITHASH | ||
cargo check |
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.
This doesn't play nicely with rustup default
as a dev. I think using the MSRV directly +1.30.0
will be the most useful in catching syntax features that make new code work, but old code fails.
But fuzz only works on +stable
? So maybe just using that directly will catch "most" things.
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.
Not all cargo
s have +X
support, only rustup, so we can't really use it without adding a ton of complexity. Nothing really wrong with using a given version, either, though.
ci/check-each-commit.sh
Outdated
git rebase $UPSTREAM/main | ||
for COMMITHASH in `git log --format=format:%H $UPSTREAM/main...HEAD`; do | ||
git checkout $COMMITHASH | ||
cargo check |
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.
Calling these manually, for now, seems OK. When more work is done to make the build/test workflow cleaner with some wrapper scripts this can just be converted.
ci/check-each-commit.sh
Outdated
for COMMITHASH in `git log --format=format:%H $UPSTREAM/main...HEAD`; do | ||
git checkout $COMMITHASH | ||
cargo check | ||
cd fuzz && cargo check --features=stdin_fuzz && cd .. |
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.
Making fuzz opt-in with a flag might be a good idea to make this easy on developers. This gets into longer-than-a-coffee-break territory with just a few patches in a stack.
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.
Hmm, it really shouldnt - cargo check does some caching, so while the first commit might take a minute, the later ones should all be pretty much instant. More importantly, breaking fuzz compile is one of the most common issues, so it'd be kinda bad to default it off.
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.
Ah yes. I read this as running the fuzz tests. I completely agree that these should be built.
df813fe
to
5caf6eb
Compare
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 did some manual testing of this to see how it goes in my workflow.
After successful completion, this leaves you in a detached head state. Anything that can be done about that?
74373a0
to
131b883
Compare
Heh, gotta bring back rebase :) |
ci/check-each-commit.sh
Outdated
for COMMITHASH in `git log --reverse --format=format:%H $1...HEAD`; do | ||
git checkout $COMMITHASH | ||
cargo check | ||
cd fuzz && cargo check --features=stdin_fuzz && cd .. |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
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.
Heh, well that got rewritten anyway....test the current version?
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.
Two minor things and this is good to go. I tested it locally on my branches against upstream as well as dependent branches against origin and it does what it says.
@@ -0,0 +1,5 @@ | |||
#!/bin/sh | |||
set -e | |||
set -x |
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.
The current progress is hidden as the rebase progresses. I tested a few things locally and I think something like git log -1 --oneline
at the top here is enough to let me know where we are in the stack.
I also really like the side-effect of being able to fix my issue in the middle of a rebase instead of having to create a temp branch, fix, rebase.
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.
Hmm, if it fails it should leave it where it was when it failed, no?
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.
Yes, when it fails it leaves it in the rebase where I can make changes which is great.
When it doesn't fail it is still nice to see the progress which explains the --oneline
131b883
to
4d9532a
Compare
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.
ACK 4d9532a
All my local testing went well and it passed in CI.
No description provided.