-
Notifications
You must be signed in to change notification settings - Fork 649
Transit CI to GitHub Actions #1942
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
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @smarnach (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
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.
- GitHub Actions has not yet support allow_failures option, so we set fail-fast to false to prevent failure on nightly to cancel the entire CI process.
That's unfortunate that they don't support allowing failures. Your handling of this sounds right!
- I have no experience of handling Percy token. Need some help to check the correctness.
It looks like Percy has some documentation about setting up GitHub Actions? Does that help?
* Not sure how to configure GitHub with bors correctly. I followed [this](https://github.com/rust-osdev/x86_64/blob/master/bors.toml) [](/rust-osdev/x86_64/blob/HEAD@{2019-12-07T16:46:47Z}/bors.toml)
We're actually using the main rust-lang org's bors instance now, sorry about the confusion because of out-of-date documentation in this repo! I think when we're ready to switch to github actions, we'll need to make a change similar to this one in rust-central-station.
@jtgeibel I know you've worked on the CI config lately, so I'd love for you to review this PR too! |
- Add `-D warnings` to `RUSTFLAGS`. Ref: f896a8e - Remove unnecessary `--force` flag of diesel installation
Percy builds in GitHub Actions has already integrated with the token. Seems no changes need. And this build is from the last commit b188188. However it failed here and I cannot figure out why. It should be exact the same build from travis-ci. I've also test upgrade Chrome in CI environment but the build still got an error and differed |
Hm what is the binary file named |
Strange! In the GitHub Actions logs you linked to where the percy API call failed, if I scroll back up a bit I see:
When the frontend tests run in Travis, I also see logs like that in the middle of the test run, but I also see them again near the end, so twice total, which also happens to be the number of parallel splits we're running the tests with. To test this theory, could you try removing the If that works, another thing to try would be to set the percy environment variables for the test job-- like Could you please try those two things? If neither work, I'll do some more investigating. 😅 Let me know! |
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.
Overall, this looks really good to me. As you mentioned, my biggest concern is that we may run into issues with the size of our caches.
In order to trigger a build, I've taken this PR and pushed it to a branch (after adding the branch name to the list). The build should now be visible on the Actions tab. I also forced a rebuild, so the logs should show successful cache hits.
uses: actions/cache@v1 | ||
with: | ||
path: ~/.rustup | ||
key: ${{ runner.os }}-rustup-${{ matrix.rust }}-${{ hashFiles('**/Cargo.lock') }} |
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'm not sure if it is necessary to include the -${{ hashFiles('**/Cargo.lock') }}
portion for this directory and for the ~/.cargo/
paths below. (It definitely makes sense for the target/
directory.) My reasoning is that the contents of these directories shouldn't really be affected by the contents of the lock file.
By the same reasoning, -${{ matrix.rust }}
may also not be necessary for many of these.
If you're unsure about removing it though, I definitely don't see this as a blocker. This is probably a micro-optimization given the expected size of these directories.
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.
Thanks. We need figure out when to invalidate old cache. Maybe some trick like script//ci/cargo-clean-on-new-rustc-version.sh, but I am not sure how to implement that.
For some reason, the beta branch (and only beta) has failed twice on the same test now.
The test isn't failing on Travis, so that's a bit strange. 😕 |
☔ The latest upstream changes (presumably #1944) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
There is a binary file named 3a8c2f23
.
Also, this PR is not enough to be able to gate bors on GitHub Actions: an unfortunate part of GHA is it doesn't provide a green or red check when the whole workflow passes or fails, but it just reports the individual checks. That means there is no single value we can put in bors's configuration file.
On Crater and (soon) on rustc the approach we've taken is to add a "success" and "failure" jobs with the same display name: both of them have all the other jobs as needs:
, and one is if: success()
while the other is if: !success()
. That allows to gate on the bors build finished
check.
I've tried but still failed on parallel one.
Maybe there are network issues on GitHub Actions? Here are environment variables:
|
Removed. Thanks!
Current Github Actions does not support |
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.
Current Github Actions does not support allow_failures config on job/matrix. Though we can let it fail silently but it is not the right way to handle it in my opinions.
Well, we still need to have a single job that needs:
everything we gate on, otherwise we won't be able to integrate bors with GitHub Actions.
Yeah, I'm seeing the download graph not load in Percy on a different PR, so I think that's unrelated to GitHub Actions. I'm going to investigate that a bit today. |
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.
Looks great to me! Let's see what the other team members say.
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.
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.
LGTM!
push: | ||
branches: | ||
- auto | ||
- try |
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.
On travis we need to include the master
branch, because it's (well technically the repo HEAD
) cache is used as the fallback for new branches and PRs. That doesn't seem to apply to the caching logic on GH Actions, so I think its okay to drop it here.
@bors r+ |
📌 Commit d201c50 has been approved by |
Transit CI to GitHub Actions # What Transit the CI process to GitHub Actions. Close #1903 [Live GitHub Actions of this PR](https://github.com/weihanglo/crates.io/actions?query=workflow%3ACI+) # Details - Create two independent jobs, Frontend and Backend, to run in parallel. - The pre-installed Rust in the environment of Github Actions is installed under root privileges. That makes tarball cache fails to restore. Instead, we install Rust via rustup script manually. - GitHub Actions has not yet support `allow_failures` option, so we set` fail-fast` to false to prevent failure on nightly to cancel the entire CI process. - Update all documents mentioned Travis-CI to GitHub Actions. # Need helps - I have no experience of handling Percy token. Need some help to check the correctness. - Not sure how to configure GitHub with bors correctly. I followed [this](https://github.com/rust-osdev/x86_64/blob/master/bors.toml) and set the status to job names.
☀️ Test successful - checks-travis |
What
Transit the CI process to GitHub Actions.
Close #1903
Live GitHub Actions of this PR
Details
allow_failures
option, so we setfail-fast
to false to prevent failure on nightly to cancel the entire CI process.Need helps