Add basic unit testing

.github/workflows/push.yaml

@@ -8,8 +8,27 @@ on:
     - main
 
 jobs:
+  test:
+    name: Test
+    runs-on: ubuntu-20.04
+    steps:
+    - name: Checkout
+      uses: actions/checkout@v4
+    - name: Set up Python
+      uses: actions/setup-python@v4
+      with:
+        python-version: '3.x'
+    - name: Install dependencies
+      run: |
+        python -m pip install --upgrade pip
+        pip install -r requirements.txt
+    - name: Test with pytest
+      run: |
+        pip install pytest
+        pytest
   publish-docker:
     name: Build and Push fastapi container
+    needs: test
     runs-on: ubuntu-20.04
     permissions:
       contents: 'read'

.gitignore

@@ -1 +1,2 @@
-app/__pycache__
+app/__pycache__
+app/.pytest_cache

README.md

@@ -17,11 +17,13 @@ You can see the basic kubernetes manifests to make this work in `/kubernetes`.
 
 ## Update on Docker Push
 
-To deploy a new image for this service, see the github action in [push.yaml](.github/workflows/push.yaml).  This action has two phases, but you likely would also want to run some unit tests and some other things in your own github actions.
+To deploy a new image for this service, see the github action in [push.yaml](.github/workflows/push.yaml).  This implements a pretty common process for releasing a build artifact: unit test -> docker build -> deploy.
 
-The first job in the workflow uses the docker metadata action to generate a set of tags, then buildx to build, tag and push the image to ghcr.  You can see all the built images easily [here](https://github.com/pluralsh/plrl-cd-test/pkgs/container/plrl-cd-test).  We use ghcr for convenience but you can easily leverage any other docker registry, and most cloud's kubernetes distros natively integrate w/ their own registries so it's worth considering them as options.
+The first job in the workflow basically just sets up python and runs a trivial pytest for demo purposes.  You'll likely have a much more complex test harness for a more mature application.
 
-The second job configures the `plural` cli using the `pluralsh/setup-plural` action then runs `plural cd services update` to reconfigure and redeploy the service.  In particular the syntax is:
+The second job in the workflow uses the docker metadata action to generate a set of tags, then buildx to build, tag and push the image to ghcr.  You can see all the built images easily [here](https://github.com/pluralsh/plrl-cd-test/pkgs/container/plrl-cd-test).  We use ghcr for convenience but you can easily leverage any other docker registry, and most cloud's kubernetes distros natively integrate w/ their own registries so it's worth considering them as options.
+
+The final job configures the `plural` cli using the `pluralsh/setup-plural` action then runs `plural cd services update` to reconfigure and redeploy the service.  In particular the syntax is:
 
 ```sh
 plural cd services update @<cluster-handle>/<service-name> --conf <var>=<value> (...can add more configuration updates as needed)

app/test_main.py

@@ -0,0 +1,9 @@
+from fastapi.testclient import TestClient
+
+from .main import app
+
+client = TestClient(app)
+
+def test_read_root():
+    response = client.get("/")
+    assert response.status_code == 200

requirements.txt

@@ -1,2 +1,3 @@
 fastapi~=0.103
-uvicorn~=0.23
+uvicorn~=0.23
+httpx