test deploying demo

.github/workflows/tests_ci.yaml

@@ -21,68 +21,68 @@ jobs:
       run: |
         ./dependencies/install_dependencies.sh
 
-    - name: Test
+    - name: Run demo
       run: |
-        echo hi
-
-  ci:
-    # 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 `./tune/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
+        ./scripts/run_demo.sh
+
+  # ci:
+  #   # 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 `./tune/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

scripts/run_demo.sh

@@ -0,0 +1,2 @@
+#!/bin/bash
+python -m streamlit tune.demo.main