From 84c019ed08549543662a37130bad999d280a1712 Mon Sep 17 00:00:00 2001 From: WayneGoosen <13494899+WayneGoosen@users.noreply.github.com> Date: Sat, 29 Jun 2024 14:24:52 +0200 Subject: [PATCH] feat: complete part 2 blog post --- ...eployment-guide-part-2-gitHub-workflow.mdx | 73 +++++++++++-------- 1 file changed, 44 insertions(+), 29 deletions(-) diff --git a/src/content/blog/streamlit-deployment-guide-part-2-gitHub-workflow.mdx b/src/content/blog/streamlit-deployment-guide-part-2-gitHub-workflow.mdx index 8f0cc1d..d1b45bb 100644 --- a/src/content/blog/streamlit-deployment-guide-part-2-gitHub-workflow.mdx +++ b/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,7 +126,7 @@ jobs: #### Workflow Definition -``` +```yaml name: Docker Image Build and Push ``` @@ -122,10 +134,10 @@ The name of the workflow which is shown under the Actions tab. This allows you t #### 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,7 +224,7 @@ 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 ``` @@ -220,7 +232,7 @@ 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