docs: move all bazel testing info to a single location #46084
Conversation
| - Test package in node: `yarn bazel test packages/core/test:test` | ||
| - Test package in karma: `yarn bazel test packages/core/test:test_web` | ||
| - Test all packages: `yarn bazel test packages/...` | ||
| - Test package in node: `yarn test packages/core/test:test` | ||
| - Test package in karma: `yarn test packages/core/test:test_web` | ||
| - Test all packages: `yarn test packages/...` |
There was a problem hiding this comment.
I think that bazel is not necessary
actually the script seem to use bazelisk (I guess they are the same-ish?):
| Bazel is used as the primary tool for building and testing Angular. Building and testing are | ||
| incremental with Bazel, and it's possible to only run tests for an individual package instead | ||
| of for all packages. Read more about this in the [BAZEL.md](./BAZEL.md) document. |
There was a problem hiding this comment.
I don't think that explaining why bazel is used adds much here
docs/DEVELOPER.md
Outdated
|
|
||
| **Note**: The first test run will be much slower than future runs. This is because future runs will | ||
| benefit from Bazel's capability to do incremental builds. | ||
| However the tests will be executed on our Continuous Integration infrastructure. So if you forgot to run the tests and some broke github will present you with the CI errors which you can then fix. |
There was a problem hiding this comment.
Honestly I have never run locally all the tests, on my (dinosaur) machine it would take ages, so I think it could be valuable to suggest to do that, but provide the alternative to rely on the CI
There was a problem hiding this comment.
Technically if you run everything once locally, you would get the same caching benefits as CI, but in practice this is obviously still slower. Just want to avoid recommend to rely fully on CI. Ideally folks would run some tests for the parts they have changed. e.g. if I change the compiler, I run tests in the compiler/test Bazel package.
There was a problem hiding this comment.
Yeah the first run is definitely my issue, after that the tests do run rather quick
anyways I hope that the wording here is fine then, sort of letting developers know that CI checks will be performed but not actively recommending to rely solely on that
dario-piotrowicz
changed the title
dario-piotrowicz
changed the title
docs/DEVELOPER.md
Outdated
|
|
||
| **Note**: The first test run will be much slower than future runs. This is because future runs will | ||
| benefit from Bazel's capability to do incremental builds. | ||
| However the tests will be executed on our Continuous Integration infrastructure. So if you forgot to run the tests and some broke github will present you with the CI errors which you can then fix. |
There was a problem hiding this comment.
Technically if you run everything once locally, you would get the same caching benefits as CI, but in practice this is obviously still slower. Just want to avoid recommend to rely fully on CI. Ideally folks would run some tests for the parts they have changed. e.g. if I change the compiler, I run tests in the compiler/test Bazel package.
instead of presenting the same (or similar information) in both the DEVELOPER.md and the BAZEL.md files, more all the information in the BAZEL file and refer to that section in the DEVELOPER file
dario-piotrowicz
force-pushed
the
BAZEL_DEVELOPER_TESTING
branch
from
67ad7b9
to
d374fdf
Compare
AndrewKushnir
added
action: merge
|
Merge-assistance: the |
AndrewKushnir
added
the
action: merge-assistance
|
This PR was merged into the repository by commit f04a8ea. |
instead of presenting the same (or similar information) in both the DEVELOPER.md and the BAZEL.md files, more all the information in the BAZEL file and refer to that section in the DEVELOPER file PR Close #46084
instead of presenting the same (or similar information) in both the DEVELOPER.md and the BAZEL.md files, more all the information in the BAZEL file and refer to that section in the DEVELOPER file PR Close #46084
instead of presenting the same (or similar information) in both the
DEVELOPER.md and the BAZEL.md files, more all the information in the
BAZEL file and refer to that section in the DEVELOPER file
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Issue
Issue Number: N/A
Does this PR introduce a breaking change?
Other information
...in the DEVELOPER one, which seemed quite valuable for the BAZEL file as well, instead of copy that section I just figured that the DEVELOPER's md should just point to the BAZEL one and that one should be the only point of reference (as it also contains various information for debugging)