-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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: migrate browser tests to GHA #27675
Conversation
.github/workflows/ci.yml
Outdated
# yarn integration-tests:size-test || yarn ci-notify-slack-failure components-ci-size-tracking | ||
|
||
test: | ||
runs-on: ubuntu-latest-4core |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we are hitting a point where we should discuss/audit that we are not regressing with our CI times- especially given the lower spec'ed host VMs compared to CircleCI. Do we have any data here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have anything, but I would prefer that we start low and find we need to up them instead of just jumping to big runners right away.
Unfortunately I haven't been able to find a good way to "benchmark" to be able to say what we should use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for being a little pushy about this. I just think it's important to keep CI times similar to before. Historically Angular components had the fastest wall time of CI across all repositories and I feel strongly that we want to keep this. We should not simply switch to GitHub actions, use significantly different runners without auditing/comparing.
Even if we are saying we can revisit in the future- in practice we will likely never do this. We are not immediately jumping to big runners- but we should audit/compare and understand the impact on the Bazel host etc. We are just looking at not regressing in CI wall time. Additionally smaller runners might incur the same cost as larger runners which take fewer minutes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also capturing this here (not related to runner size I assume), I'm seeing a 10min time for lint, while on CircleCI it took 2min. See: https://github.com/angular/components/actions/runs/6034665778/job/16373509530
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did some testing and found that 16core is the sweet spot of speed/cost.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect. Thanks for looking more.
9ef4e08
to
76e8e89
Compare
@devversion PTAL |
a84f7aa
to
76cd4b4
Compare
I think I was waiting on #27675 (comment). |
Migrate browser tests to Github Actions
76cd4b4
to
7ce58a8
Compare
Notify on slack when a test fails on the upstream branch
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Migrate browser tests to Github Actions