feat: complete part 2 blog post

src/content/blog/streamlit-deployment-guide-part-2-gitHub-workflow.mdx

@@ -2,10 +2,8 @@
 heroImage: /src/assets/images/dockergithubactions.png
 category: CICD
 description: >-
-  Configure a GitHub workflow to build the Dockerfile and publish the image to
-  ghcr.io
-pubDate: 2024-06-17T22:00:00.000Z
-draft: true
+  A step-by-step guide to configure a GitHub Workflow that builds a Docker image from your Streamlit app and publishes it to GitHub Container Registry (ghcr.io).
+pubDate: 2024-06-29
 tags:
   - github actions
   - github
@@ -15,7 +13,7 @@ title: >-
   to ghcr.io
 ---
 
-This showcases a Github workflow walkthrough of building and publishing a Docker image to GitHub Container Registry. It continues a series detailing the process of deploying Streamlit app to Azure, broken down into the following parts:
+This showcases a GitHub Workflow walkthrough of building and publishing a Docker image to GitHub Container Registry. It continues a series detailing the process of deploying Streamlit app to Azure, broken down into the following parts:
 
 - [**Part 1**: Containerizing a Streamlit app.](https://blog.waynegoosen.com/post/streamlit-deployment-guide-part-1-containerization/)
 - **Part 2**: GitHub Workflow for Building and Publishing to ghcr.io **You are here** 😊
@@ -26,10 +24,24 @@ Do you want to deploy your Streamlit application on Azure right now? Use the [te
 
 ## TL;DR
 
-Read the [completed GitHub workflow](#completed-workflow).
+See the [completed GitHub Workflow](#completed-workflow).
+
+## Prerequisites
+
+A basic understanding of GitHub Actions is required and the Workflow assumes you have the files from Part 1:
+
+- /app/Dockerfile
+- /app/app.py
+- /app/requirements.txt
+- /app/.streamlit/config.toml
+- gitversion.yml
+
+If you have your own Dockerfile, ensure all the dependent files are available and are stored within /app folder for this Workflow to function correctly.
 
 ## Create a GitHub Workflow
 
+The Workflow file should be stored within the following folder: `.github/workflows/`. A concise name could be `docker-image-build-and-push.yaml`.
+
 ### Completed Workflow
 
 ```yaml
@@ -114,18 +126,18 @@ jobs:
 
 #### Workflow Definition
 
-```
+```yaml
 name: Docker Image Build and Push
 ```
 
 The name of the workflow which is shown under the Actions tab. This allows you to set a readable name for your Workflow, if omitted the file name will be shown.
 
 #### Triggers
 
-```
+```yaml
 on:
   push:
-    branches: [ "main" ]
+    branches: ['main']
     paths:
       - 'app/**'
   workflow_dispatch:
@@ -135,16 +147,16 @@ The workflow triggers on pushes to the "main" branch and only if the changes are
 
 #### Concurrency
 
-```
-currency:
-- group: build-and-push-image
+```yaml
+concurrency:
+  - group: build-and-push-image
 ```
 
 This ensures that if the workflow is triggered again while a previous run is in progress, the new run will queue until the previous one completes.
 
 #### Jobs
 
-```
+```yaml
 jobs:
   build-and-push-image:
     runs-on: ubuntu-latest
@@ -156,9 +168,9 @@ jobs:
 There is a single job defined which covers the full behavior to build and push the image. 'runs-on' specifies it should run on the latest version of Ubuntu.
 'env' allows you to set environment variables available to all tasks within the job. 'REGISTRY' represents the Docker registry and is set to 'ghcr.io'
 
-#### permissions
+#### Permissions
 
-```
+```yaml
 permissions:
   contents: write
   packages: write
@@ -170,7 +182,7 @@ Grants the necessary permissions for the job to interact with the repository. Co
 
 ##### 1. Checkout the Repository
 
-```
+```yaml
 - name: Checkout repository
   uses: actions/checkout@v4
   with:
@@ -181,7 +193,7 @@ Checks out the repository to the job runner. Allowing the runner to access the r
 
 ##### 2. Get Owner/Repo Name and Convert to Lowercase
 
-```
+```yaml
 - name: Get owner/repo name and convert to lowercase
   id: get-image-name
   run: echo "image-name=$(echo ${{ github.repository }} | tr '[:upper:]' '[:lower:]')" >> $GITHUB_OUTPUT
@@ -191,7 +203,7 @@ Retrieves the repository name and converts it to lowercase for use as the Docker
 
 ##### 3. Install GitVersion for Versioning
 
-```
+```yaml
 - name: Install GitVersion
   uses: gittools/actions/gitversion/setup@v1.1.1
   with:
@@ -202,7 +214,7 @@ Installs GitVersion tool for semantic versioning. This tool is used to generate
 
 ##### 4. Execute GitVersion to Get the Version Number
 
-```
+```yaml
 - name: Use GitVersion
   id: gitversion
   uses: gittools/actions/gitversion/execute@v1.1.1
@@ -212,15 +224,15 @@ Runs GitVersion execute to generate the semantic version number. It sets the ver
 
 ##### 5. Set Up Git User for Tagging
 
-```
+```yaml
 - uses: fregante/setup-git-user@v2
 ```
 
 Sets up Git user for tagging purposes.
 
 ##### 6. Create a New Tag Based on the Version Number
 
-```
+```yaml
 - name: Create Tag
   run: git tag -a ${{ steps.gitversion.outputs.semVer }} -m "Auto-generated tag from GitHub Action."
 ```
@@ -229,7 +241,7 @@ Creates a new Git tag based on the version number generated by GitVersion.
 
 ##### 7. Push the Newly Created Tags to the Repository
 
-```
+```yaml
 - name: Push Tags
   run: git push origin --tags
 ```
@@ -238,7 +250,7 @@ Pushes the created tag to the GitHub repository.
 
 ##### 8. Log in to the Container Registry
 
-```
+```yaml
 - name: Log in to the Container registry
   uses: docker/login-action@v3.2.0
   with:
@@ -251,7 +263,7 @@ Logs into the container registry using the GitHub actor and token.
 
 ##### 9. Build and Push the Docker Image to the Registry
 
-```
+```yaml
 - name: Build and push Docker image
   uses: docker/build-push-action@v5.3.0
   with:
@@ -264,17 +276,20 @@ Logs into the container registry using the GitHub actor and token.
 
 Builds and pushes the Docker image to the specified registry with the appropriate tags. The context is set to the 'app' directory, and the image is tagged with both 'latest' and the semantic version.
 
-## What is gitversion?
+## What is GitVersion?
 
 GitVersion is a tool that helps automate versioning of software projects based on Git commit history, providing a consistent and reliable way to generate version numbers for different branches and releases. [Read the documentation](https://gitversion.net/docs/)
 
-### gitversion Configuration
+### Generated Version Number Example
+
+How the version is generated is based on how you set up your GitVersion configuration file. Assume we used the [configuration file](#example-gitversionyml-configuration) and start with version 1.0.0 along with using [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/). Example commit history and resulting versions:
 
-The provided gitversion file contains configuration settings for the GitVersion tool, which is used to generate a version for our Docker image. It specifies the versioning scheme, commit message patterns for incrementing versions, fallback tags, and other options related to continuous delivery and versioning.
+- fix: resolve login bug -> Generated Version: `1.0.1`
+- feat: add user profile page -> Generated Version: `1.1.0`
 
-The main point is that it uses the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) specification to create the version number.
+### Example gitversion.yml Configuration
 
-#### Configuration file
+The provided GitVersion file contains configuration settings for the GitVersion tool, basically it defines the rules on how the version will be generated. See [configuration documentation](https://gitversion.net/docs/reference/configuration) for in-depth explanations.
 
 ```yaml
 assembly-versioning-scheme: MajorMinorPatch