Skip to content
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

put the list of tests run in CI behind a ::group #134910

Open
jyn514 opened this issue Dec 30, 2024 · 6 comments
Open

put the list of tests run in CI behind a ::group #134910

jyn514 opened this issue Dec 30, 2024 · 6 comments
Assignees
Labels
A-CI Area: Our Github Actions CI A-contributor-roadblock Area: Makes things more difficult for new contributors to rust itself A-testsuite Area: The testsuite used to check the correctness of rustc C-enhancement Category: An issue proposing an enhancement or a PR with one. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@jyn514
Copy link
Member

jyn514 commented Dec 30, 2024

right now, scrolling through a CI log to find a failed test takes quite a while. it would be nice to hide all the successful tests by default so that the failed tests show up right away. we do something similar already for compiling.

this may be kinda tricky because compiletest needs to print this after all the tests have run, but before libtest prints the test report. there might be a hook for this and there might not.

@rustbot label A-contributor-roadblock A-testsuite

@rustbot rustbot added needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. A-contributor-roadblock Area: Makes things more difficult for new contributors to rust itself A-testsuite Area: The testsuite used to check the correctness of rustc labels Dec 30, 2024
@ranger-ross
Copy link
Contributor

I'd like to take a shot at implementing this if no one else is already working on it.

@rustbot claim

@matthiaskrgr
Copy link
Member

right now, scrolling through a CI log to find a failed test takes quite a while

do you have an example?
When I click on / curl the plain logs, most of the time the failing tests are directly at the bottom. 🤔

@jieyouxu jieyouxu added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. A-CI Area: Our Github Actions CI C-enhancement Category: An issue proposing an enhancement or a PR with one. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Dec 30, 2024
@jieyouxu
Copy link
Member

@matthiaskrgr the plain-text log IME loads quite fast and the jump-to-bottom usually works. However the plain-text log has a bunch of unrendered color codes which makes it very annoying to look at, so sometimes you look at the (web) interface. The web interface can be hard to scroll down because it doesn't load all at once...

@matthiaskrgr
Copy link
Member

When I curl the plaintext into a terminal, I actually get the fully colored logs displayed as stdout, as the color control chars are dumped straight into the terminal which then renders as it always would.
This makes it much easier to find some errors than it would when looking through a black and white plaintext imo.

The web interface is broken as often I can't even scroll down far enough to see the error 😆

@ranger-ross
Copy link
Contributor

Not directly related to the tests but I noticed that the Docker cache hash key input (pre-hashed) is getting dumped here

cat $hash_key

This ends up taking up a pretty good chunk of the non-collapsed logs.

Few examples pulled at random from the Actions tab

I think we could probably add a ::group around this, or simply remove this log completely since the actual hash is printed just a few lines later

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 30, 2024
…obzol

ci: Cleanup docker build logs in CI

Cleaning up the CI logs to make reviewing CI failures easier. This PR adds a `::group` around the docker tag hash input which is pretty large (250+ lines) and is probably not relevant for most people.

Related to rust-lang#134910 , see this [comment](rust-lang#134910 (comment))
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Dec 30, 2024
Rollup merge of rust-lang#134924 - ranger-ross:cleanup-ci-output, r=Kobzol

ci: Cleanup docker build logs in CI

Cleaning up the CI logs to make reviewing CI failures easier. This PR adds a `::group` around the docker tag hash input which is pretty large (250+ lines) and is probably not relevant for most people.

Related to rust-lang#134910 , see this [comment](rust-lang#134910 (comment))
@ranger-ross
Copy link
Contributor

I did some research on this and I have a few thoughts.

Currently we already have a ::group wrapping the entire test run (ie. Testing stage2 compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu)). GitHub Actions does not support nested log groupings yet (see actions/toolkit#1001) so it would be some what difficult make the output nice using ::group.

I am thinking we instead create a new test report format in render_tests.rs specifically for CI.

Current format

  running 18205 tests
  ...i.....................................................i.............iiiiiii.ii.......    88/18205
  ...........ii.........................i.i.i.............................................   176/18205
  .........................................................ii.iiiiiiiiiiiiiii....i.......i   264/18205

Proposed format

  running 18205 tests
 10%  -- 88/18205, 71 passed, 11 ignored, 0 failed
 20%  -- 176/18205, 171 passed, 21 ignored, 0 failed
 ...
 100% -- 18205/18205, 17205 passed, 400 ignored, 20 failed

Another idea would be to add a job summary with the failed tests + logs.
This works, but tbh I am not in love with GH job summary they are a bit difficult to find in the Web UI. (since the Details link in the PR takes you to logs page, the job summaries are often over looked in my experience)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-CI Area: Our Github Actions CI A-contributor-roadblock Area: Makes things more difficult for new contributors to rust itself A-testsuite Area: The testsuite used to check the correctness of rustc C-enhancement Category: An issue proposing an enhancement or a PR with one. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants