Skip to content

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

Merged
merged 12 commits into from
Dec 21, 2019
Merged

Transit CI to GitHub Actions #1942

merged 12 commits into from
Dec 21, 2019

Conversation

weihanglo
Copy link
Member

@weihanglo weihanglo commented Dec 7, 2019

What

Transit the CI process to GitHub Actions.

Close #1903

Live GitHub Actions of this PR

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 and set the status to job names.

@rust-highfive
Copy link

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.

Copy link
Member

@carols10cents carols10cents left a 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.

@carols10cents
Copy link
Member

@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
@weihanglo
Copy link
Member Author

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

@carols10cents
Copy link
Member

carols10cents commented Dec 11, 2019

Hm what is the binary file named 3a8c2f23 that was added?

@carols10cents
Copy link
Member

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

Strange! In the GitHub Actions logs you linked to where the percy API call failed, if I scroll back up a bit I see:

[percy] Finalizing build...
[percy] Visual diffs are now processing: https://percy.io/crates-io/crates.io/builds/3415214

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.

Percy's documentation mentions that the percy client has automatic support for parallel test runners on Travis CI.

To test this theory, could you try removing the --split=2 --parallel from the test command and see if GitHub actions is able to send all the screenshots to percy?

If that works, another thing to try would be to set the percy environment variables for the test job-- like PERCY_PARALLEL_NONCE=date +%s PERCY_PARALLEL_TOTAL=2 ember exam --split=2 --parallel or similar.

Could you please try those two things? If neither work, I'll do some more investigating. 😅 Let me know!

Copy link
Member

@jtgeibel jtgeibel left a 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') }}
Copy link
Member

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.

Copy link
Member Author

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.

@jtgeibel
Copy link
Member

For some reason, the beta branch (and only beta) has failed twice on the same test now.

 thread 'krate::new_krate' panicked at 'Could not run jobs: NoMessageReceived', src/libcore/result.rs:1165:5

The test isn't failing on Travis, so that's a bit strange. 😕

@bors
Copy link
Contributor

bors commented Dec 12, 2019

☔ The latest upstream changes (presumably #1944) made this pull request unmergeable. Please resolve the merge conflicts.

Copy link
Member

@pietroalbini pietroalbini left a 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.

https://github.com/rust-lang/crater/blob/a1930d2acd71382b66ce68d9e45ce57f350fae1a/.github/workflows/bors.yml#L125-L149

@weihanglo
Copy link
Member Author

weihanglo commented Dec 13, 2019

To test this theory, could you try removing the --split=2 --parallel from the test command and see if GitHub actions is able to send all the screenshots to percy?

If that works, another thing to try would be to set the percy environment variables for the test job-- like PERCY_PARALLEL_NONCE=date +%s PERCY_PARALLEL_TOTAL=2 ember exam --split=2 --parallel or similar.

Could you please try those two things? If neither work, I'll do some more investigating. 😅 Let me know!

@carols10cents

I've tried but still failed on parallel one.

  • Without any parallel tests, it passed breezily. Percy build
  • With a PERCY_PARALLEL_NONCE, it seems that CI uploaded correct snapshots but still failed to fetch the image on /crates/:crate. Percy build

Maybe there are network issues on GitHub Actions?

Here are environment variables:

Run npm test
  npm test
  shell: /bin/bash -e {0}
  env:
    JOBS: 1
    PERCY_PARALLEL_TOTAL: 2
    PERCY_TOKEN: 0d8707a02b19aebbec79bb0bf302b8d2fa95edb33169cfe41b084289596670b1
    PERCY_PROJECT: crates-io/crates.io
    PERCY_PARALLEL_NONCE: 1576200325

> cargo@0.0.0 test /home/runner/work/crates.io/crates.io
> ember exam --split=2 --parallel

@weihanglo
Copy link
Member Author

@pietroalbini

There is a binary file named 3a8c2f23.

Removed. Thanks!

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.

https://github.com/rust-lang/crater/blob/a1930d2acd71382b66ce68d9e45ce57f350fae1a/.github/workflows/bors.yml#L125-L149

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.

Copy link
Member

@pietroalbini pietroalbini left a 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.

@carols10cents
Copy link
Member

* With a `PERCY_PARALLEL_NONCE`, it seems that CI uploaded correct snapshots but still failed to fetch the image on `/crates/:crate`. [Percy build](https://percy.io/crates-io/crates.io/builds/3462405)

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.

Copy link
Member

@pietroalbini pietroalbini left a 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.

Copy link
Member

@carols10cents carols10cents left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm good with this! I want to make sure @jtgeibel approves too, and I still need to take care of the crate download graph not loading in Percy... I'm trying to fix that in #1948 but I haven't gotten it working yet.

Copy link
Member

@jtgeibel jtgeibel left a 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
Copy link
Member

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.

@jtgeibel
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Dec 21, 2019

📌 Commit d201c50 has been approved by jtgeibel

@bors
Copy link
Contributor

bors commented Dec 21, 2019

⌛ Testing commit d201c50 with merge 7e562c6...

bors added a commit that referenced this pull request Dec 21, 2019
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.
@bors
Copy link
Contributor

bors commented Dec 21, 2019

☀️ Test successful - checks-travis
Approved by: jtgeibel
Pushing 7e562c6 to master...

@bors bors merged commit d201c50 into rust-lang:master Dec 21, 2019
@weihanglo weihanglo deleted the chore/github-actions branch January 3, 2020 05:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Try out GitHub Actions
7 participants