-
Notifications
You must be signed in to change notification settings - Fork 16.4k
Run parallel tests for ARM platform #50198
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
Conversation
5f4d41f to
0fb76c6
Compare
f9d99d0 to
9ce9f07
Compare
gopidesupavan
left a comment
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.
Super cool, now we have both :)
jason810496
left a comment
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.
Rerun the test as it seems to be flaky.
amoghrajesh
left a comment
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.
👏🏽
726a785 to
221fc39
Compare
|
For now I disabled the "pull request" trigger: The tests will run:
This will not have impact on regular PRs and we will have time to observe stability |
Since we have `ubintu22.04-arm` public runners available, we should be able to run a set of parallel tests for ARM - this would make our ARM images move out of experimental phase. We are not running "all" tests - only those that make sense to run on ARM for "production" quality. MySQL tests have some timeouts and run longer on ARM, that's why we do not run MySQL tests on ARM as well. We can also get rid of the "ARM collection" test that was introduced to test if just **collection** of tests when we remove packages that shoud not be installed on ARM works. But if we are running actual pytest tests on ARM, we do not need to run those tests any more.
Since we have `ubintu22.04-arm` public runners available, we should be able to run a set of parallel tests for ARM - this would make our ARM images move out of experimental phase. We are not running "all" tests - only those that make sense to run on ARM for "production" quality. MySQL tests have some timeouts and run longer on ARM, that's why we do not run MySQL tests on ARM as well. We can also get rid of the "ARM collection" test that was introduced to test if just **collection** of tests when we remove packages that shoud not be installed on ARM works. But if we are running actual pytest tests on ARM, we do not need to run those tests any more. (cherry picked from commit 3198aad) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
Since we have `ubintu22.04-arm` public runners available, we should be able to run a set of parallel tests for ARM - this would make our ARM images move out of experimental phase. We are not running "all" tests - only those that make sense to run on ARM for "production" quality. MySQL tests have some timeouts and run longer on ARM, that's why we do not run MySQL tests on ARM as well. We can also get rid of the "ARM collection" test that was introduced to test if just **collection** of tests when we remove packages that shoud not be installed on ARM works. But if we are running actual pytest tests on ARM, we do not need to run those tests any more. (cherry picked from commit 3198aad)
Since we have
ubintu22.04-armpublic runners available, we should be able to run a set of parallel tests for ARM - this would make our ARM images move out of experimental phase.We are not running "all" tests - only those that make sense to run on ARM for "production" quality.
MySQL tests have some timeouts and run longer on ARM, that's why we
do not run MySQL tests on ARM as well.
We can also get rid of the "ARM collection" test that was introduced
to test if just collection of tests when we remove packages that
shoud not be installed on ARM works. But if we are running actual
pytest tests on ARM, we do not need to run those tests any more.
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.