diff options
| -rw-r--r-- | .github/workflows/dev-branch.yml | 2 | ||||
| -rw-r--r-- | .github/workflows/main-branch.yml | 6 | ||||
| -rw-r--r-- | .github/workflows/main-pr.yml | 14 | ||||
| -rw-r--r-- | README.md | 65 | ||||
| -rw-r--r-- | docker/dev/Dockerfile (renamed from Dockerfile.dev) | 0 | ||||
| -rw-r--r-- | docker/docker-compose.yml (renamed from docker-compose.yml) | 0 | ||||
| -rw-r--r-- | docker/prod/Dockerfile (renamed from Dockerfile) | 0 | ||||
| -rw-r--r-- | kubernetes/demo-production-server-deployment.yaml (renamed from demo-production-server-deployment.yaml) | 0 |
8 files changed, 62 insertions, 25 deletions
diff --git a/.github/workflows/dev-branch.yml b/.github/workflows/dev-branch.yml index 95d580a..7198d8e 100644 --- a/.github/workflows/dev-branch.yml +++ b/.github/workflows/dev-branch.yml @@ -86,5 +86,5 @@ jobs: with: push: true context: . - file: Dockerfile.dev + file: ./docker/dev/Dockerfile tags: ${{ secrets.DOCKERHUB_USERNAME }}/pico-web-dev:latest diff --git a/.github/workflows/main-branch.yml b/.github/workflows/main-branch.yml index f19976d..9c933ef 100644 --- a/.github/workflows/main-branch.yml +++ b/.github/workflows/main-branch.yml @@ -5,7 +5,7 @@ on: - main jobs: Build-docker-and-push: - name: Build the docker container image and push it to dockerhub + name: Build the production docker container image and push it to dockerhub runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 @@ -18,6 +18,8 @@ jobs: - uses: docker/build-push-action@v5 with: push: true + context: . + file: ./docker/prod/Dockerfile tags: ${{ secrets.DOCKERHUB_USERNAME }}/pico-web-server:latest Release: @@ -30,4 +32,4 @@ jobs: env: GITHUB_TOKEN: ${{ secrets.TOKEN_GITHUB }} with: - bump_version_scheme: minor + bump_version_scheme: norelease # PR must have one of these labels: release:major, release:minor, release:patch diff --git a/.github/workflows/main-pr.yml b/.github/workflows/main-pr.yml new file mode 100644 index 0000000..c122af8 --- /dev/null +++ b/.github/workflows/main-pr.yml @@ -0,0 +1,14 @@ +name: Check for release label inside pull request +on: + pull_request: + types: [opened, edited, ready_for_review, review_requested] + branches: + - 'main' +jobs: + has_release_label: + if: ! contains(github.event.pull_request.labels.*.name, 'release:major') && + ! contains(github.event.pull_request.labels.*.name, 'release:minor') && + ! contains(github.event.pull_request.labels.*.name, 'release:patch') + runs-on: ubuntu-latest + steps: + - run: exit 1 @@ -3,42 +3,63 @@ Small client-server application. The server receives a URL from a client and returns the appropriate page. -URIs (URLs) are in the form `userinfo@address:portPATH`, where `address` and `port` could be skipped. -The userinfo section is analogous to subdomains in normal web applications. +## DevOps lifecycle -It's assumed that all pages are written in Markdown so the client adds special "rendering" like hyperlinks and bold text (via ANSI escape sequences). -The server is configured to send pages only in allowed directories, and can handle multiple directories with custom error pages. +### 1. Plan -## From issue to production +With [GitHub issues](https://github.com/Syndamia/pico-web/issues) modifications to the project are started and discussed - +### 2. Code -1. A [GitHub issue](https://github.com/Syndamia/pico-web/issues) is created when something needs to be added/changed in the project -2. Then a developer makes the appropriate branch (which I call the "feature branch"), where they push updates to the codebase. - On every commit a small pipeline is ran, executing all tests and static analysis. -3. Upon completion, a merge request is made to the `dev` branch. After the GitHub workflow is successful and a mandatory review, it will be merged. -4. Then, on the new commit, a new workflow is started on the `dev` branch, doing again the tests and static analysis, alongside the security analysis. - Afterwards, the development binaries are built and the [development Docker image](https://hub.docker.com/r/syndamia/pico-web-dev) is deployed. -5. After enough changes have accumulated, another pull request is made, from `dev` to `main` (PRs to `main` are only done from `dev`). - On successful workflow and mandatory review, the changes can be merged. -6. Finally, a pipeline from the `main` branch will be ran, deploying the [production server Docker image](https://hub.docker.com/r/syndamia/pico-web-server) and creating a new GitHub release. +Our branching strategy is a "feature workflow with stable branches", meaning: -Although there is no deployment to a managed kubernetes cluster (too expensive), a Deployment with the [demo](./demo) files is available: +- a feature branch is created for each issue +- after the issue is resolved in that branch, it is merged into the `dev` branch +- after enough time has passed, the `dev` branch is merged into the `main` branch -```bash -kubectl apply -f demo-production-server-deployment.yaml -``` +You must only push commits to feature branches. +Code can be added to `dev` only via pull requests from feature branches. +Code can be added to `main` only via pull requests from `dev`. + +Merge requests must always be approved by a contributor and `dev` merge requests to `main` must always have one of these labels: `release:major`, `release:minor` or `release:patch`. + +### 3. CI + +On each push to feature branches and `dev` we execute the "feature-branch" pipeline, during which we run: + +- SAST: unit tests, [clang](TODO)'s `--analyze` static analysis and [flawfinder](TODO)'s security analysis <!-- and SonarCloud, Trivy --> +<!-- +- SCA: https://github.com/multilang-depends/depends +--> +- the `Makefile` for building our application -## Building and usage +### 4. CD -Build the binaries: +On each successful merge request to `dev`, + +- a development docker image is deployed to [dockerhub](https://hub.docker.com/r/syndamia/pico-web-dev) and +- the development Kubernetes cluster is deployed with [minikube](TODO) in the pipeline + +On each successful merge request to `main`, + +- the production docker image is deployed to [dockerhub](https://hub.docker.com/r/syndamia/pico-web), +- the production Kubernetes cluster is deployed with [minkube](TODO) in the pipeline and +- a [GitHub release](https://github.com/Syndamia/pico-web/releases) is created, according to the pull request label ```bash -make +kubectl apply -f demo-production-server-deployment.yaml ``` +## Project details + You get two binaries, `server` and `browser`. +URIs (URLs) are in the form `userinfo@address:portPATH`, where `address` and `port` could be skipped. +The userinfo section is analogous to subdomains in normal web applications. + +It's assumed that all pages are written in Markdown so the client adds special "rendering" like hyperlinks and bold text (via ANSI escape sequences). +The server is configured to send pages only in allowed directories, and can handle multiple directories with custom error pages. + ### Browser The `browser` program takes no arguments. diff --git a/Dockerfile.dev b/docker/dev/Dockerfile index 328f4a6..328f4a6 100644 --- a/Dockerfile.dev +++ b/docker/dev/Dockerfile diff --git a/docker-compose.yml b/docker/docker-compose.yml index 661fd21..661fd21 100644 --- a/docker-compose.yml +++ b/docker/docker-compose.yml diff --git a/Dockerfile b/docker/prod/Dockerfile index e850445..e850445 100644 --- a/Dockerfile +++ b/docker/prod/Dockerfile diff --git a/demo-production-server-deployment.yaml b/kubernetes/demo-production-server-deployment.yaml index 62e140d..62e140d 100644 --- a/demo-production-server-deployment.yaml +++ b/kubernetes/demo-production-server-deployment.yaml |