Add instructions on the CI pipeline and app configuration

.github/workflows/build.yml

@@ -20,11 +20,19 @@ jobs:
       - name: Running tests
         uses: docker/build-push-action@v6
         with:
-          push: false
           target: test
+          push: false
+
+      # - name: Login to Docker Hub
+      #   uses: docker/login-action@v3
+      #   with:
+      #     username: ${{ secrets.DOCKERHUB_USERNAME }}
+      #     password: ${{ secrets.DOCKERHUB_TOKEN }}
 
       - name: Build production image
         uses: docker/build-push-action@v6
         with:
-          push: false
           target: production
+          push: false
+          # push: true
+          # tags: blackskad/go-web-scaffold:latest

README.md

@@ -8,7 +8,7 @@ The main entry point is in `/main.go`, however the web logic will live in `/pkg/
 
 ### Docker image
 
-While the app can be build and run with straight Go, it's intended to be build and run inside a docker container. The Dockerfile contains four stages:
+While the app can be build and run with plain Go commands, it's intended to be build and run inside a docker container. The Dockerfile contains four stages:
 
 * Base: this layer copies all the files into the Go image and pulls in all the Go mod dependencies.
 
@@ -22,6 +22,18 @@ While the app can be build and run with straight Go, it's intended to be build a
 
 To allow you to easily run the service locally without much local config, a docker-compose.yaml file is included. This file will include everything to run a minimal stack.
 
+### CI pipeline - GitHub only
+
+The project contains a GitHub Actions configuration file to run the docker build stages on `push` and `pull_requests`. It will first run the `test` stage, then it run the `production` stage.
+
+While it will build the production image, the workflow is not configured to push the image to a docker image registry. You will have to uncomment the docker login job, change the `push` argument for the production job to `true`, and set a proper image tag.
+
+In your GitHub repository, there is an option to configure rulesets for your main branch. Within the ruleset, the success of the build workflow can be made required for each pull requests. For more information, please see the [GitHub documentation](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-status-checks-to-pass-before-merging).
+
+### App configuration
+
+The main configuration will be done through environment variables. The environment package will parse the environment variables into a struct that can then be passed around through the service.
+
 ### Profiling
 
 The service always runs with pprof enabled on port 6060. This allows you to fetch runtime profiling information on `http://localhost:6060/debug/pprof`