-
Notifications
You must be signed in to change notification settings - Fork 16.3k
Run "api_internal" tests in CI #30518
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
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
934b046 to
b2ea777
Compare
Member
Author
|
I realized the internal_api tests were all skipped after the feature flag change (and the reason was that the env vars from ci.yml were not passed to inside docker-compose) - I extracted that change from this PR to #30521 |
While adding a feature flag for AIP-44 I noticed that due to a weird naming we have in tests, the "api_internal" tests were actually excluded from running - this was due to a combination of factors: * When API tests are are run, only "api" and "api_connexion" were added to API_tests * We already have "api" folder in "tests" (for experimental api) * finding "Other" tests should cover it but it exluded "api" tests but the way it is implemented, it took the "api" prefix and excluded all the test directories that were starting with "api" (including "api_internal/*" ones This change addresses it twofold: * The "api_internal" tests are added explicitly to the "API" test type * The "tests/api" folder with tests for the experimental API has been renamed to "api_experimental" (including integration tests) This should set the "internal_api" tests to run in the API test type, and renaming the "api" to api_experimental should avoid accidental skipping the tests in case someone adds "tests/api_SOMETHING" in the future.
b2ea777 to
73c2b86
Compare
uranusjr
reviewed
Apr 7, 2023
uranusjr
reviewed
Apr 7, 2023
scripts/docker/entrypoint_ci.sh
Outdated
| else | ||
| CLI_TESTS=("tests/cli") | ||
| API_TESTS=("tests/api" "tests/api_connexion") | ||
| API_TESTS=("tests/api_experimental" "tests/api_connexion" "tests/api_internal/") |
Member
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 here
Co-authored-by: Tzu-ping Chung <[email protected]>
uranusjr
approved these changes
Apr 7, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While adding a feature flag for AIP-44 I noticed that due to a weird naming we have in tests, the "api_internal" tests were actually excluded from running - this was due to a combination of factors:
This change addresses it twofold:
This should set the "internal_api" tests to run in the API test type, and renaming the "api" to api_experimental should avoid accidental skipping the tests in case someone adds "tests/api_SOMETHING" in the future.
^ 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 newsfragments.