TuningAgent interface #61
Workflow file for this run
This file contains 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
| name: Static, Unit, Integration, and End-to-End Tests | |
| on: | |
| push: {} | |
| pull_request: | |
| branches: [main] | |
| jobs: | |
| tests: | |
| # The code for the self-hosted runners is at https://github.com/wangpatrick57/dbgym-runners. | |
| runs-on: self-hosted | |
| steps: | |
| - uses: actions/checkout@v2 | |
| - name: Set up Python | |
| uses: actions/setup-python@v4 | |
| with: | |
| python-version: '3.10' | |
| # We could choose to set up dependencies manually in the GHA runner instead of installing them during the GHA. | |
| # | |
| # However, I think it's better to do them in the GHA itself so that we're testing our dependency installation step | |
| # in addition to our actual code. It also removes the need to manually reinstall dependencies on the GHA runners | |
| # every time we add a new dependency. | |
| # | |
| # Note that the GHA runners are stateful. Dependencies installed from previous runs will still be on the runner. | |
| # This means this step will usually be pretty fast as most dependencies will already be cached. However, it also | |
| # means that past runs might interfere with the current run, so you sometimes may need to restart the GHA runners. | |
| # We need to do `. "$HOME/.cargo/env"` in each step for it to work. | |
| - name: Install dependencies | |
| run: | | |
| ./dependencies/install_dependencies.sh | |
| - name: Check formatting | |
| run: | | |
| ./scripts/check_format.sh | |
| - name: Static type checking | |
| run: | | |
| ./scripts/mypy.sh | |
| - name: Run unit tests | |
| # Unit tests are defined as tests which don't require any external systems to be running. | |
| run: | | |
| . "$HOME/.cargo/env" | |
| ./scripts/run_unit_tests.sh | |
| - name: Run integration tests | |
| # Integration tests do require external systems to be running (most commonly a database instance). | |
| # Unlike end-to-end tests though, they test a specific module in a detailed manner, much like a unit test does. | |
| env: | |
| # We set `INTENDED_DBDATA_HARDWARE` so that it's seen when `integtest_pg_conn.py` executes `./env/set_up_env_integtests.sh`. | |
| INTENDED_DBDATA_HARDWARE: ssd | |
| run: | | |
| . "$HOME/.cargo/env" | |
| export | |
| ./scripts/run_integration_tests.sh | |
| - name: Run end-to-end tests | |
| # End-to-end tests are like integration tests in that they require external systems to be running. | |
| # Unlike integration tests though, they don't perform detailed checks for any individual module. | |
| # | |
| # Note that we need to run with a non-root user in order to start Postgres. This is configured in the .yaml | |
| # file for our self-hosted GHA runners. | |
| run: | | |
| . "$HOME/.cargo/env" | |
| python -m scripts.run_protox_e2e_test ssd |