feat: add a docs target into the pipeline (#129)

* feat: docs target

* fix: change docs uses to pages

* docs: add the new stage

* fix: docs ci pipeline

.github/workflows/ci.yml

@@ -144,6 +144,18 @@ jobs:
       dockerhub_username: ${{ secrets.dockerhub_username }}
       earthly_runner_address: ${{ secrets.earthly_runner_address }}
       earthly_runner_secret: ${{ secrets.earthly_runner_secret }}
+  docs:
+    uses: ./.github/workflows/pages.yml
+    needs: [build, check, package, test]
+    with:
+      aws_role_arn: ${{ inputs.aws_role_arn }}
+      aws_region: ${{ inputs.aws_region }}
+      ci_cli_version: ${{ inputs.ci_cli_version }}
+      earthfile: ./docs
+      target: docs
+    secrets:
+      earthly_runner_address: ${{ secrets.earthly_runner_address }}
+      earthly_runner_secret: ${{ secrets.earthly_runner_secret }}
   release:
     uses: ./.github/workflows/release.yml
     needs: [build, check, package, test]

docs/src/onboarding/index.md

@@ -77,12 +77,13 @@ flowchart LR
     A[Check] --> B[Build] --> C[Package] --> D[Test]
     D --> E[Release]
     D --> F[Publish]
+    D --> G[Docs]
 ```
 
 The full CI process consists of combining the discovery and execution mechanisms into a complete pipeline, as shown above.
 Each of the boxes represent a distinct stage which consists of discovering and then executing a target.
-As previously mentioned, some stages, like the `release` and `publish` stages, have additional logic that occurs after executing the
-target.
+As previously mentioned, some stages, like the `release`, `publish`, and `docs` stages,
+have additional logic that occurs after executing the target.
 
 Each stage is self-contained and the only dependency occurs when validating that the previous stage was successful.
 For example, the `build` stage will not execute until the `check` stage has passed.
@@ -115,6 +116,7 @@ However, as a short introduction, here is a brief summary of each one:
    After the image is built by executing the target, the CI will perform other steps to transform the image.
    For example, tagging it with the git commit hash and performing general static analysis.
    The CI will automatically build and publish this image to configured registries during certain types of git events.
+1. `docs` - This stage is expected to build and publish documentation.
 
 Each of the above stages are purely optional and can be combined to perform different types of CI workflows.
 For smaller projects, only a number of stages will be utilized initially.