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

CI logs should be split by build steps, or stages at the very least. #70472

Open
eddyb opened this issue Mar 27, 2020 · 4 comments
Open

CI logs should be split by build steps, or stages at the very least. #70472

eddyb opened this issue Mar 27, 2020 · 4 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@eddyb
Copy link
Member

eddyb commented Mar 27, 2020

Right now most of the build is under a single "run the build" CI step, which results in massive logs (e.g. #70468), even if for common tasks like looking at a failure, only a small part is relevant.

At the very least we could do something like this to split it up:

  • ./x.py build --stage 0
  • ./x.py build --stage 1
  • ./x.py build
  • ./x.py test

This would be trickier with distcheck, I suppose, not sure how relevant that is.

It might also be slightly slower, so we should measure it.

cc @rust-lang/infra

@jonas-schievink jonas-schievink added C-enhancement Category: An issue proposing an enhancement or a PR with one. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. labels Mar 27, 2020
@kennytm

This comment has been minimized.

@Mark-Simulacrum
Copy link
Member

Hm, I think that's for jobs, not steps though? We (for example) install the AWS tools in a separate step today and don't copy things around.

@pietroalbini
Copy link
Member

That's surely possible, but I have no clue what the impact on our configuration would be (as we'd need different sets of steps).

@Mark-Simulacrum
Copy link
Member

Yes, I think personally this would only be viable if GitHub provided a way to "start" a step dynamically -- similar to Travis' folders which were based on printing a message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. 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