From 2c6de339ad9b4e5611deea34cbccc4aa8630d50e Mon Sep 17 00:00:00 2001
From: Jiakai Li
Date: Wed, 18 Dec 2024 15:32:03 +1300
Subject: [PATCH] Update README.md - continuous integration
---
.github/workflows/ci.yml | 2 +-
README.md | 48 ++++++++++++++++++++++++++++++++++++++--
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index a23dd03..a1b048a 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -13,7 +13,7 @@ jobs:
name: Build Docker image and run end-to-end tests
runs-on: ubuntu-latest
steps:
- - name: Checkout code from Github
+ - name: Checkout code from GitHub
uses: actions/checkout@v3
- name: Run end-to-end tests
run: >
diff --git a/README.md b/README.md
index 265615a..94d1663 100644
--- a/README.md
+++ b/README.md
@@ -66,8 +66,8 @@ In this way you don't force `pytest` to be installed with main dependencies. You
## Static Code Analysis and Security Scanning
This project uses [black](https://black.readthedocs.io/en/stable) to flag any formatting inconsistencies in your code,
-[isort](https://pycqa.github.io/isort)(seems not being actively maintained anymore) to ensure that your import statements stay organized according to the official recommendation, and
-[flake8](https://github.com/PyCQA/flake8)(seems not being actively maintained anymore) to check for any other PEP 8 style violations.
+[isort](https://pycqa.github.io/isort) (seems not being actively maintained anymore) to ensure that your import statements stay organized according to the official recommendation, and
+[flake8](https://github.com/PyCQA/flake8) (seems not being actively maintained anymore) to check for any other PEP 8 style violations.
```bash
(.venv) $ python -m black src/
(.venv) $ python -m isort src/
@@ -203,3 +203,47 @@ The command overwrite makes sure that we are using a production grade webserver
- It will not handle more than one request at a time by default.
- If you leave debug mode on and an error pops up, it opens up a shell that allows for arbitrary code to be executed on your server (think os.system('rm -rf /')).
- The development server doesn't scale well.
+
+## Run End-to-End Tests
+
+The docker compose can be used to set up a test container for running the end-to-end test. The [profiles](https://docs.docker.com/compose/how-tos/profiles) can be used to mark the test container service:
+```yaml
+services:
+# ...
+
+ test:
+ profiles:
+ - testing # This is a helpful feature
+ build:
+ context: ./web
+ dockerfile: Dockerfile.dev # Dockerfile.dev bundles the testing framework
+ environment:
+ REDIS_URL: "redis://redis:6379"
+ FLASK_URL: "http://web:8000"
+ networks:
+ - backend-network
+ depends_on:
+ - redis
+ - web
+ command: >
+ sh -c 'python -m pytest test/e2e/ -vv
+ --redis-url $$REDIS_URL
+ --flask-url $$FLASK_URL'
+```
+
+## Define a Docker-Based Continuous Integration Pipeline
+
+Depending on your team structure, experience, and other factors, you can choose from different source control branching models, also known as [workflows](https://www.atlassian.com/git/tutorials/comparing-workflows).
+
+Once the code is hosted on git, [GitHub Actions](https://docs.github.com/en/actions) let you specify one or more workflows triggered by certain events, like pushing code to a branch or opening a new pull request. Each workflow can define a number of jobs consisting of steps, which will execute on a runner.
+Each step of a job is implemented by an action that can be either:
+- A custom shell command or a script
+- A GitHub Action defined in another GitHub repository
+
+In the [workflow CI file](./.github/workflows/ci.yml), we defined below four activities, which are quite self-explanatory
+- Checkout code from GitHub
+- Run end-to-end tests
+- Login to Docker Hub
+- Push image to Docker Hub
+
+And this completes this note.