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

Let CI distinguish test compilation and test run failures #15600

Merged
merged 6 commits into from
Jan 4, 2023

Conversation

mherrmann
Copy link
Collaborator

@mherrmann mherrmann commented Oct 21, 2022

Prerequisite for https://github.com/brave/devops/issues/8517.

At the moment, we have a single command for running tests: npm run test. This both builds and runs the tests. If the command fails, then it is unclear whether the failure was in building or running the tests. This leads to confusing error messages in our CI. The present PR is a preparation for fixing this.

This PR also incorporates a few small refactorings. Most notably, it introduces internal buidTests and runTests functions that better separate those concerns.

Submitter Checklist:

  • I confirm that no security/privacy review is needed, or that I have requested one
  • There is a ticket for my issue
  • Used Github auto-closing keywords in the PR description above
  • Wrote a good PR/commit description
  • Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
  • Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
  • Checked the PR locally: npm run test -- brave_browser_tests, npm run test -- brave_unit_tests, npm run lint, npm run gn_check, npm run tslint
  • Ran git rebase master (if needed)

Reviewer Checklist:

  • A security review is not needed, or a link to one is included in the PR description
  • New files have MPL-2.0 license header
  • Adequate test coverage exists to prevent regressions
  • Major classes, functions and non-trivial code blocks are well-commented
  • Changes in component dependencies are properly reflected in gn
  • Code follows the style guide
  • Test plan is specified in PR before merging

After-merge Checklist:

Test Plan:

@mherrmann mherrmann self-assigned this Oct 21, 2022
@mherrmann mherrmann requested review from bridiver and a team as code owners October 21, 2022 19:33
@mherrmann mherrmann force-pushed the better-test-error-reporting branch 2 times, most recently from 004c5e1 to 15ce857 Compare October 31, 2022 06:41
@mherrmann mherrmann force-pushed the better-test-error-reporting branch 3 times, most recently from 2d35a52 to 3ef92d5 Compare November 8, 2022 05:16
Copy link
Member

@petemill petemill left a comment

Choose a reason for hiding this comment

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

package.json changes seem fine. Please get another approval for the code changes before merge. I was only able to cursory review and whilst there are some minor issues (top-level anonymous functions and using let instead of const, that whole file has them and we need to improve the linter to catch these).

@mherrmann mherrmann requested a review from a team as a code owner November 8, 2022 13:58
const buildTestsCommand = program.command('build_tests <suite>');
const runTestsCommand = program.command('run_tests <suite>');

[testCommand, buildTestsCommand, runTestsCommand].forEach((command) => {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this would be a lot simpler if we had an optional --target param for the build command. Separately we should do the same thing for create_dist

Copy link
Collaborator

Choose a reason for hiding this comment

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

for backwards compat you change package.json for npm run test to handle this as two commands

Copy link
Collaborator Author

@mherrmann mherrmann Nov 10, 2022

Choose a reason for hiding this comment

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

I think this would be a lot simpler if we had an optional --target param for the build

We have such a param, don't we? For example:

npm run build -- --target=brave/components/policy:pack_policy_templates

I'm pretty sure I'm not fully understanding what you wrote. Could you clarify in more detail what you meant?

PS - as always ty for the review.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

for backwards compat you change package.json for npm run test to handle this as two commands

I'm afraid I don't understand the message of this comment either. Yes I'm changing package.json in a way that's backwards compatible (while also retaining the test command for developer ease). Is there something I should change?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@bridiver could I ask you to clarify your comments?

@mherrmann mherrmann force-pushed the better-test-error-reporting branch from b42364d to 0879d7f Compare December 15, 2022 14:36
Previously, the command exited with a non-zero code on both compilation
and test errors. This made it impossible to determine which of the two
happened - and thus hard to decide whether to generate test reports.
@mherrmann mherrmann force-pushed the better-test-error-reporting branch from cd8cd1a to 87e0af1 Compare December 19, 2022 17:31
@mherrmann mherrmann changed the title Introduce separate build- and run_test commands Let CI distinguish test-compilation and -run failures Dec 19, 2022
@mherrmann mherrmann changed the title Let CI distinguish test-compilation and -run failures Let CI distinguish test compilation and test run failures Dec 19, 2022
@mihaiplesa mihaiplesa requested a review from bridiver December 23, 2022 10:21
@mherrmann mherrmann merged commit 30be63f into master Jan 4, 2023
@mherrmann mherrmann deleted the better-test-error-reporting branch January 4, 2023 08:03
@github-actions github-actions bot added this to the 1.48.x - Nightly milestone Jan 4, 2023
mherrmann added a commit that referenced this pull request Jan 4, 2023
Previously, `npm run test --output` exited with a non-zero code on both
compilation and test errors. This made it impossible to determine which
of the two happened - and thus hard to decide whether to generate test
reports. Now, the command exits with 0 on test failures. (Note that the
behavior is unchanged when --output is not given. That is, in this case
you still get non-zero exit codes for test failures.)
mherrmann added a commit that referenced this pull request Jan 4, 2023
Previously, `npm run test --output` exited with a non-zero code on both
compilation and test errors. This made it impossible to determine which
of the two happened - and thus hard to decide whether to generate test
reports. Now, the command exits with 0 on test failures. (Note that the
behavior is unchanged when --output is not given. That is, in this case
you still get non-zero exit codes for test failures.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants