azure-functions-python-worker icon indicating copy to clipboard operation
azure-functions-python-worker copied to clipboard

test: run supported tests with emulators

Open hallvictoria opened this issue 1 year ago • 0 comments

Description

Converts blob, table, queue, generic, and event hub tests to run using emulators. Updates CODEOWNERS file, adds retries for flaky unit tests.

  • Adds a new workflow for running these tests: ci-emulator-tests.yml
    • This workflow will run as part of the public build and official build
    • It can be run as part of the public build because it doesn't have any secrets
    • It can also be run with sdk and extensions releases
  • Refactors these tests into a new emulator_tests folder
    • This means that those tests will no longer interact with prod resources and skips them for the E2E tests
  • Starts the emulators through tests/emulator_tests/utils/docker-compose.yml
    • This docker-compose file starts both the Azurite storage emulator and the EventHub emulator in a single place
  • Generic tests can be run with emulators because they use table storage
  • Deferred binding blob tests require a connection string to run properly and cannot be run using emulators
  • EventHub emulator support:
    • Event Hub resources defined in Config.json
    • Emulator started in docker-compose.yml
  • Note: two separate ci-emulator-tests.yml files
    • A linux pool is required to spin up the Docker container
    • For official-build, the top level pool must be windows. To run a job using a linux pool as part of the official-build, it must be defined in the job template (example: docker consumption & dedicated tests)
    • There is a different pool for public and internal, and pools can't be mixed between orgs (public pool can't be used in an internal pipeline and vice versa)
    • Conditionally setting or using a variable to set the pool is not allowed in the internal org (Validate Hosted Pool Information stage fails)
    • Therefore, the only way to run tests that require a linux pool in both the official and public builds is to create two separate templates

Fixes #


PR information

  • [ ] The title of the PR is clear and informative.
  • [ ] There are a small number of commits, each of which has an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
  • [ ] If applicable, the PR references the bug/issue that it fixes in the description.
  • [ ] New Unit tests were added for the changes made and CI is passing.

Quality of Code and Contribution Guidelines

hallvictoria avatar Aug 16 '24 15:08 hallvictoria