Skip to content

Composite GitHub Actions for building/deploying Hugo sites to Azure

License

Notifications You must be signed in to change notification settings

kevholmes/hugo-azure-actions

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

12 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Composite Actions deploying Hugo sites to Azure

Composite GitHub Actions for Hugo projects deploying to Azure

  1. generate-metadata
  2. build
  3. deploy

Example workflow invoking these Actions

I am utilizing release-please-action from Google to handle semantic versioning and cutting releases via PRs in repos where these hugo/azure pipelines are used. It's also used within this repo hugo-azure-actions to generate Releases that follow the traditional GitHub Actions semver format where you can specify @major, @major.minor or @major.minor.patch when invoking each of them. See available releases.

These Actions workflows and their CI/CD process are based on a simple GitHub PR-Ops flow:

  1. PR opened, or additional commits to an opened PR will build and deploy the Hugo site to dev.site-base-tld
  2. A Release-Please generated PR is opened that contains one or more Conventional Commits PRs (e.g.: feat, fix) will be built and deployed to stg.site-base-tld each time that release PR is opened or updated if more feature/fix PRs are merged into the branch it's monitoring.
  3. A Release-Please generated PR is merged into mainline, triggering a Release/tag event in GitHub, which will trigger a build/deploy to site-base-tld - typically, this would be your production environment.

The two central values to tweak here if you want to follow the above process are:

  • hugo-version
  • site-base-tld

If you'd like to utilize these workflows similarly, I've included a sample cd.yml workflow below to place within the GitHub repo hosting your Hugo site's code. This, in conjunction with a sample release-please.yml workflow in that same Hugo code repo will provide the Release Please PR/semantic versioning automation if you use Conventional Commits for PR titles.

# .github/workflows/cd.yml
name: cd

on:
  pull_request:
    types: [ synchronize, opened ]
  release:
    types:
      - released

defaults:
  run:
    shell: bash

concurrency: cd

jobs:
  gen-metadata:
    runs-on: ubuntu-latest
    outputs:
      build-id: ${{ steps.build-metadata.outputs.artifact-id }}
      build-domain: ${{ steps.build-metadata.outputs.composite-domain }}
      env-target: ${{ steps.build-metadata.outputs.env-target }}
      hugo-version: ${{ steps.build-metadata.outputs.hugo-version }}
    steps:
      - name: generate build metadata
        id: build-metadata
        uses: kevholmes/hugo-azure-actions/.github/actions/generate-metadata@v1
        with:
          hugo-version: 0.118.2
          site-base-tld: cloverstack.dev
  build:
    runs-on: ubuntu-latest
    needs: gen-metadata
    environment:
      name: ${{ needs.gen-metadata.outputs.env-target }}
      url: ${{ needs.gen-metadata.outputs.build-domain }}
    steps:
      - name: checkout source
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: build hugo site
        uses: kevholmes/hugo-azure-actions/.github/actions/build@v1
        with:
          build-id: ${{ needs.gen-metadata.outputs.build-id }}
          build-domain: ${{ needs.gen-metadata.outputs.build-domain }}
          hugo-version: ${{ needs.gen-metadata.outputs.hugo-version }}
  deploy-azure:
    runs-on: ubuntu-latest
    needs: [gen-metadata, build]
    environment:
      name: ${{ needs.gen-metadata.outputs.env-target }}
      url: ${{ needs.gen-metadata.outputs.build-domain }}
    steps:
      - name: deploy hugo site to azure
        uses: kevholmes/hugo-azure-actions/.github/actions/deploy@v1
        with:
          build-id: ${{ needs.gen-metadata.outputs.build-id }}
          az-client-id: ${{ vars.CLIENT_ID }}
          az-client-secret: ${{ secrets.CLIENT_SECRET }}
          az-subscription-id: ${{ vars.SUBSCRIPTION_ID }}
          az-tenant-id: ${{ vars.TENANT_ID }}
          az-storage-acct: ${{ vars.AZ_STORAGE_ACCT }}
          az-cdn-profile-name: ${{ vars.AZ_CDN_PROFILE_NAME }}
          az-cdn-endpoint: ${{ vars.AZ_CDN_ENDPOINT }}
          az-resource-group: ${{ vars.AZ_RESOURCE_GROUP }}

In the Release Please workflow below, RELEASER_TOKEN is a privileged PAT associated with a user. GitHub Actions now prevents the Actions bot user from triggering downstream workflows due to CVE concerns. This would prevent the CD workflow above from executing in our scenario and building/deploying the staged release generated by Release-Please.

# .github/workflows/release-please.yml
name: release-please

on:
  push:
    branches:
      - main

permissions:
  contents: write
  pull-requests: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: google-github-actions/release-please-action@v3
        with:
          release-type: go
          token: ${{ secrets.RELEASER_TOKEN }}

Azure Infrastructure

This is leveraging Azure Storage's Static Web hosting feature. I also utilize HTTPS-only and the Classic Azure CDN with auto-TLS rotation for the development environments. Three environments (dev, stg, prod) in this setup cost me $2.40 to $5.00 (USD) a month, depending on CDN traffic load.

If you'd like to see how this Azure infrastructure is set up, the Pulumi code describing it all is located at kevholmes/elyclover.com-infra.

About

Composite GitHub Actions for building/deploying Hugo sites to Azure

Resources

License

Stars

Watchers

Forks