DEV Community: TED Vortex (Teodor Eugen Duțulescu)

Deploy a GitHub Application to Cloudflare Workers

TED Vortex (Teodor Eugen Duțulescu) — Tue, 22 Feb 2022 23:56:47 +0000

Introduction

"why, why, WHY?"

After seeing @bdougieyo build a ProBot app and @blackgirlbytes fresh take on deploying ProBot to AWS Lambda, I figured I would spice things up a bit by researching the most cost-effective solution to run a serverless GitHub application.

Before I go on, you might be thinking things like:

only care about money?!
AWS Lambda is dirt cheap!
it's all a configuration war you cannot win!

Thinking about these hypothetical objections, my inner dialogue goes on:
Me: "Hold up, whaaaat?!"
Other me: "Yes it's CloudFlare Workers!"

The simple explanation is that I'm proposing use of the Service Worker API. Cloudflare offers a flat, free, 100k requests a day if you can keep it cutting edge, has local development and testing options with miniflare and a key/value (KV) store.

If you still have your doubts, it might be because you know that the build system would be using Webpack 4 out of the box. However, this means it can do Rollup, and so it can do Vite. Yes, @mtfoley, this is preparing to be another converting to Vite series!

We'll be applying our solution to catsup-app GitHub application being developed in the Open Sauced org. For each repo that has the application installed, our Discord will be updated when an issue has the good first issue label applied.

Technical part

"how to how-to X!"

Requirements

This is going to hurt:

make the existing Probot code compatible
writing less-than-browser-compatible code
<10 ms CPU execution time due to the workers' limits
automated releases over an open-source repository
secure deployments

Code

Assuming the workers PR will eventually be production ready, the code should be visible over at:

open-sauced / catsup

This app will index your pr and issue data.

🍕 Open Sauced Catsup App 🍕

The path to your next Open Source contribution

📖 Prerequisites

In order to run the project locally we need node>=16 and npm>=8 installed on our development machines.

🖥️ Local development

To run the GitHub App code against a test repository, add TEST_REPOSITORY to your local .env file.

To start the server locally at port 8888:

npm start

📦 Deploy to production

Netlify account

Install the Netlify GitHub app in the repository and configure the environment variables listed in .env.example.

GitHub App

Register a new GitHub application with the permissions issues:write and metadata:read. Set the webhook URL to <your netlify domain>/api/github/webhooks.

Once registered, you will be able to obtain all the GITHUB_APP_* credentials from the app settings.

It is advised you generate the WEBHOOK_SECRET using the following command:

# random key strokes can work too if you don't have ruby(??)
ruby

…

View on GitHub

In order for the project to be shipped as a service function, the node environment can not be used in any of the production code. Reviewing Probot source, one might see a dead end in that it uses require("dotenv").config(). However, its underlying framework, OctoKit does not come with any opinionated code in this regard.

Simply expanding the script into the Probot equivalent while dodging the node imports was very easy and has been done before. Being able to see existing working code made the process a lot more enjoyable:

gr2m / cloudflare-worker-github-app-example

A Cloudflare Worker + GitHub App Example

cloudflare-worker-github-app-example

A Cloudflare Worker + GitHub App Example

The worker.js file is a Cloudflare Worker which is continuously deployed using GitHub Actions (see .github/workflows/deploy.yml).

The worker does 2 things

GET requests: respond with an HTML website with links and a live counter of installations.
POST requests: handle webhook request from GitHub

⚠️ The requests from GitHub are currently not verified using the signature, because the code is currently using Node's crypto package. This will be resolved once I create a universal webhook verification package, similar to universal-github-app-jwt. For the time being, you could define a secret path that that webhook requests by GitHub are sent to, in order to prevent anyone who knows your workers URL from sending fake webhook requests. See #1

Step-by-step instructions to create your own

Note that you require access to the new GitHub Actions for the automated deployment to work.

Fork this…

View on GitHub

Using the same probot/smee-client shipped by Probot we divert the webhook URL to one on localhost for the development application, and for the production application we will enter a custom route.

While it might look like an anti-pattern, setting up a private local-only application in the workers configuration file is perfectly safe and meant as the most basic way to ensure all environment variables are encrypted for the production environment. In fact, a helpful property of workers lies in the fact that we are unable to deploy the app if the requisite environment variables don't exist, and the only way to add them is by encrypting them as secrets.

The above secrets definition pattern requires that we set up the GitHub application and Discord hooks before trying to deploy the service worker, as it would otherwise fail with unencrypted or loose values.

Setting up the service worker

1. Cloudflare worker

Set up a cloudflare account and enable workers, change account_id in wrangler.toml to your account id.

Go to your workers dashboard and create a new worker, select any template, adjust name in wrangler.toml if the existing one is taken.

Write the "Routes" URL provided by the worker down somewhere for the next parts. It will serve as webhook return URL.

2. GitHub application

Create a new GitHub application with scopes issues:write and metadata:read while also enabling tracking events.

Upon creation you should have plain-text values for APP_ID, CLIENT_ID.

Click the "Generate a new client secret" button and copy the resulting value of CLIENT_SECRET.

In the webhook return URL copy the value of your worker route as described in the last step of the Cloudflare setup.

If you have Ruby installed, it is advised you generate the WEBHOOK_SECRET using the following command:



# random key strokes can work too if you don't have ruby
ruby -rsecurerandom -e 'puts SecureRandom.hex(20)'

Now, go to the very bottom and click "Generate a new private key" and open a terminal in the location of the downloaded file.

Rename this file to private-key.pem for the next command to work:



openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in private-key.pem -out private-key-pkcs8.key

Copy the contents of private-key-pkcs8.key to APP_PK.

3. Discord webhook

Go to your server of choice, click "Settings" and then "Integrations", create a new webhook and copy the URL and paste that value into DISCORD_URL.

Now you are good to use the wrangler release workflows and deploy to production!

4. Environment variables

Select the "Settings" tab on your newly created worker and click "Variables", add the following variables with the values described in the previous steps:

APP_ID
APP_PK
DISCORD_URL
CLIENT_ID
CLIENT_SECRET
WEBHOOK_SECRET

Encrypt all of them and deployment will start working both locally and in the CI workflows!

Deployment

The PR code, as well as the maintainers, are not yet sure of the best way to approach deployment to multiple environments. There is a minor concern for the CI action leaking the target URL which would give the possibility of service disruption. Making the deployment target fully private, i.e. deploying from wrangler locally, would make the discovery process partially visible to us in application installations and limit outbound attack vectors considerably. Sitting behind 2 of the biggest global CDNs would also help a lot!

Local publish



npm run wrangler -- login

Now you can test all the variables are correct by publishing from the terminal:



# npm run wrangler -- publish  
npm run publish

Open up a production real time log using:



npm run wrangler -- tail

GitHub actions

Create a new GitHub actions secret named CF_API_TOKEN, get its value from Cloudflare's create a new token using the "Edit Cloudflare Workers" template.

Push new code to the server, after a release the new code should be sent to the server and instantly propagate.

Conclusion

"easy, what next?!"

Some things come to mind as potential improvements:

switching the build system to vite
implement testing and coverage commands
move secrets to KV namespaces for easier environment deployments
dockerize repository

Automatically update git major tags on GitHub marketplace release

TED Vortex (Teodor Eugen Duțulescu) — Tue, 07 Dec 2021 08:08:46 +0000

Motivation

Having previously dockerized our semantic release configuration in @open-sauced/semantic-release-conventional-config, a manual step was needed to publish the action in the GitHub marketplace.

This meant that forcing a major tag update with @semantic-release/exec as part of the release process was possible, but would result in the major tag (for example v3) linking to a valid repository commit SHA that is not actually released in the marketplace.

Sensibly solving these issues required:

keeping the semantic release configuration intact
testing the action container in another repository
having a maintainer manually edit and save the release
letting the marketplace.yml workflow update major tags in the curated release context

It may sound tedious but in practice, all a maintainer has to do to update the marketplace tags is edit a published release and press the save button. That's exactly 2 clicks from the repository front page and the simplest way to have acceptance testing.

My Workflow

name: "Action major version tag"

on:
  release:
    types:
      - published
      - edited

jobs:
  latest:
    name: Update action tags
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: ${{ github.ref }}

      - name: "🚀 publish action"
        uses: Actions-R-Us/actions-tagger@v2
        with:
          publish_latest_tag: false
          prefer_branch_releases: false

The full workflow is available here: .github/workflows/marketplace.yml

Submission Category: Maintainer Must-Haves

Yaml File or Link to Code

Live repository using this workflow:

open-sauced / semantic-release-conventional-config

semantic-release shareable config to publish to npm and/or ghcr

This project has been archived in favor of open-sauced/release

@open-sauced/semantic-release-conventional-config

semantic-release shareable config to publish to npm and/or ghcr.

now available as a GitHub Marketplace action

📦 Plugins

This shareable configuration use the following plugins:

🖥️ Requirements

Most important limitations are:

GITHUB_TOKEN for everything
NPM_TOKEN for public npm library
docker containers need to be built beforehand

You can skip here if you are using elevated Private Access Token, however we don't recommend going down that path.

No force push or admin cherries branch protections for the following branches:

main - required
next - optional, next channel
next-major - optional, next major
alpha - optional, pre-release branch
beta - optional, pre-release branch
vX[.X.X] - maintenance releases

If you use more than the main branch, optionally create an environment that is limiting where pushes can come from…

View on GitHub

Additional Resources / Info

Here are all the open source actions we are using to power this release workflow:

Actions-R-Us/actions-tagger@v2 - updates major tag on release

Be sure to include the DEV usernames of your collaborators:

Matthew FoleyFollow

I write code for fun, and sometimes for work

Semantic release to npm and/or ghcr without any tooling

TED Vortex (Teodor Eugen Duțulescu) — Tue, 07 Dec 2021 08:08:29 +0000

Motivation

Having our semantic release process available as a scoped package was a useful practice but it became obvious that having it installed in our development dependencies across multiple repositories would pose a challenge for other maintainers while increasing our build times.

The only thing that could simplify this process was to have all the release dependencies offloaded to a Docker container action we could tag major versions and reduce maintenance cost by deploying release configuration improvements without touching workflows.

My Workflow

This action is a thoroughly engineered semantic-release shareable configuration, meant to simplify configuration and workflow environment variables to just GITHUB_TOKEN and, if you are deploying to npmjs, NPM_TOKEN.

There are 2 ways of using this action in a workflow:

From a docker container without an updated marketplace tag, we use this technique to test if the action is fully working for GitHub marketplace users, before deploying and updating our major action tag. Running it this way the preferred outputs are stored to environment variables.
From the GitHub marketplace, ensuring stability and having workflow step outputs that can be cross-referenced.

There are multiple use cases for this action/workflow, we will go through them all in the next sections.

Any kind of npm package

The simplest use case for a typical NPM package, almost zero setup time on GitHub actions and no additional installed tools. Assuming there are no build steps, setting up node/npm is not required.

Release to npm from ghcr container:

name: "Release"

on:
  push:
    branches:
      - main
      - alpha
      - beta
      - next
      - next-major

jobs:
  release:
    environment:
      name: production
      url: https://github.com/${{ github.repository }}/releases/tag/${{ env.RELEASE_TAG }}
    runs-on: ubuntu-latest
    steps:
      - name: "☁️ checkout repository"
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: "🚀 release"
        id: semantic-release
        uses: docker://ghcr.io/open-sauced/semantic-release-conventional-config:3.0.0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

      - name: '♻️ cleanup'
        run: |
          echo ${{ env.RELEASE_TAG }}
          echo ${{ env.RELEASE_VERSION }}

Release to npm from marketplace action:

name: "Release"

on:
  push:
    branches:
      - main
      - alpha
      - beta
      - next
      - next-major

jobs:
  release:
    environment:
      name: production
      url: https://github.com/${{ github.repository }}/releases/tag/${{ steps.semantic-release.outputs.release-tag }}
    name: Semantic release
    runs-on: ubuntu-latest
    steps:
      - name: "☁️ checkout repository"
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: "🚀 release"
        id: semantic-release
        uses: open-sauced/semantic-release-conventional-config@v3
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

      - name: '♻️ cleanup'
        run: |
          echo ${{ steps.semantic-release.outputs.release-tag }}
          echo ${{ steps.semantic-release.outputs.release-version }}

Containerised nodejs application

This is a typical example for NodeJS backend applications or React frontends. Assuming there are no build steps or the package is set as private, setting up node/npm is not required and the docker build job will take care of all the limitations.

name: "Release"

on:
  push:
    branches:
      - main
      - alpha
      - beta
      - next
      - next-major

jobs:
  docker:
    name: Build container
    runs-on: ubuntu-latest
    steps:
      - name: "☁️ checkout repository"
        uses: actions/checkout@v2

      - name: "🔧 setup buildx"
        uses: docker/setup-buildx-action@v1

      - name: "🔧 cache docker layers"
        uses: actions/cache@v2
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-buildx-

      - name: "🔧 docker meta"
        id: meta
        uses: docker/metadata-action@v3
        with:
          images: ${{ github.repository }}
          tags: latest

      - name: "📦 docker build"
        uses: docker/build-push-action@v2
        with:
          context: .
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          outputs: type=docker,dest=/tmp/docker.tar
          push: false
          cache-from: type=gha, scope=${{ github.workflow }}
          cache-to: type=gha, scope=${{ github.workflow }}

      - name: "📂 docker artifacts"
        uses: actions/upload-artifact@v2
        with:
          name: docker
          path: /tmp/docker.tar

  release:
    environment:
      name: production
      url: https://github.com/${{ github.repository }}/releases/tag/${{ steps.semantic-release.outputs.release-tag }}
    name: Semantic release
    needs:
      - docker
    runs-on: ubuntu-latest
    steps:
      - name: "☁️ checkout repository"
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: "📂 download docker artifacts"
        uses: actions/download-artifact@v2
        with:
          name: docker
          path: /tmp

      - name: "📦 load tag"
        run: |
          docker load --input /tmp/docker.tar
          docker image ls -a

      - name: "🚀 release"
        id: semantic-release
        uses: open-sauced/semantic-release-conventional-config@v3
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: "♻️ cleanup"
        run: |
          echo ${{ steps.semantic-release.outputs.release-tag }}
          echo ${{ steps.semantic-release.outputs.release-version }}

Containerised nodejs GitHub action

This is the most niche usage, it requires building and storing the build artifact, releasing the docker container, and then updating the action.yml as part of the release process. This requires manually editing the release to push to the marketplace and updating the major action tag.

name: "Release"

on:
  push:
    branches:
      - main
      - alpha
      - beta
      - next
      - next-major

jobs:
  docker:
    name: Build container
    runs-on: ubuntu-latest
    steps:
      - name: "☁️ checkout repository"
        uses: actions/checkout@v2

      - name: "🔧 setup buildx"
        uses: docker/setup-buildx-action@v1

      - name: "🔧 cache docker layers"
        uses: actions/cache@v2
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-buildx-

      - name: "🔧 docker meta"
        id: meta
        uses: docker/metadata-action@v3
        with:
          images: ${{ github.repository }}
          tags: latest

      - name: "📦 docker build"
        uses: docker/build-push-action@v2
        with:
          context: .
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          outputs: type=docker,dest=/tmp/docker.tar
          push: false
          cache-from: type=gha, scope=${{ github.workflow }}
          cache-to: type=gha, scope=${{ github.workflow }}

      - name: "📂 docker artifacts"
        uses: actions/upload-artifact@v2
        with:
          name: docker
          path: /tmp/docker.tar

  release:
    environment:
      name: production
      url: https://github.com/${{ github.repository }}/releases/tag/${{ steps.semantic-release.outputs.release-tag }}
    name: Semantic release
    needs:
      - docker
    runs-on: ubuntu-latest
    steps:
      - name: "☁️ checkout repository"
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: "🔧 setup node"
        uses: actions/[email protected]
        with:
          node-version: 16

      - name: "🔧 install npm@latest"
        run: npm i -g npm@latest

      - name: "📦 install dependencies"
        uses: bahmutov/npm-install@v1

      - name: "📂 download docker artifacts"
        uses: actions/download-artifact@v2
        with:
          name: docker
          path: /tmp

      - name: "📦 load tag"
        run: |
          docker load --input /tmp/docker.tar
          docker image ls -a

      - name: "🚀 release"
        id: semantic-release
        uses: open-sauced/[email protected]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  cleanup:
    name: Cleanup actions
    needs:
      - release
    runs-on: ubuntu-latest
    steps:
      - name: "♻️ remove build artifacts"
        uses: geekyeggo/delete-artifact@v1
        with:
          name: |
            docker

We thought about enabling some flexibility for users wanting minimal visual changes without them having to fork the repository and release another semantic configuration.

It's possible to release the container to another private GitHub repository or the docker registry by manipulating these variables:

DOCKER_USERNAME=$GITHUB_REPOSITORY_OWNER
DOCKER_PASSWORD=$GITHUB_TOKEN

It's possible to change the release commit name and author by manipulating these variables:

GIT_COMMITTER_NAME="open-sauced[bot]"
GIT_COMMITTER_EMAIL="63161813+open-sauced[bot]@users.noreply.github.com"
GIT_AUTHOR_NAME=$GITHUB_SHA.authorName
GIT_AUTHOR_EMAIL=$GITHUB_SHA.authorEmail

Here are all the semantic-release plugins and steps explained:

@semantic-release/commit-analyzer - analyzes conventional commits deciding if they are bumping a patch, minor or major release tag
@semantic-release/release-notes-generator - generates release notes based on the analysed commits
@semantic-release/changelog - generates a fancy changelog using the repository name the workflow was run for as a title and cool emojis [example]
conventional-changelog-conventionalcommits - the conventional commit specification configuration preset
@semantic-release/npm
@google/semantic-release-replace-plugin - if the repository is deploying a containerised action, this updates action.yml with the recently released version tag
semantic-release-license - if the repository has a LICENSE* file, this updates the year
@semantic-release/git - this creates the GitHub release commit [example]
@semantic-release/github - generates GitHub release notes with added release channel links at the bottom [example]
@eclass/semantic-release-docker - if the repository has a Dockerfile, this takes care of releasing the container to ghcr.io [example]
@semantic-release/exec - used to set GitHub action environment variables when run as from docker container and GitHub action outputs when run as a marketplace action
execa - used to check the commit author and check for various settings in the repository using this action
npmlog - used to log the setup process

Submission Category: DIY Deployments

Yaml File or Link to Code

Live repository using this action in a workflow:

0-vortex / semantic-release-docker-test

Experimenting with dockerized semantic-release configuration repository for opensauced.pizza

semantic-release-docker-test

showcasing the usage of @open-sauced/semantic-release-conventional-config

🍕 Community

Got Questions? Join the conversation in our Discord.
Find Open Sauced videos and release overviews on our YouTube Channel.

⚖️ LICENSE

MIT © Open Sauced

View on GitHub

GitHub action:
@open-sauced/semantic-release-conventional-config/action.yml

GitHub container registry Dockerfile:
@open-sauced/semantic-release-conventional-config/Dockerfile

Full semantic release configuration:
@open-sauced/semantic-release-conventional-config/release.config.js

Additional Resources / Info

Here are all the open source actions we are using to power this release workflow in our repositories and examples:

actions/checkout@v2 - most performant git checkout
actions/[email protected] - we use it to set the node version to 16
actions/upload-artifact@v2 - we use it to transport our artifacts in between jobs
actions/download-artifact@v2 - we use it to download our artifacts in between jobs
docker/setup-buildx-action@v1 - we use it to setup the docker builder
actions/cache@v2 - we use it to cache docker layers
docker/metadata-action@v3 - we use it to normalise most of our docker container values
docker/build-push-action@v2 - we use this to build the container
bahmutov/npm-install@v1 - lightning fast npm ci with built-in cache
open-sauced/semantic-release-conventional-config@v3 - semantic-release configuration, docker container and GitHub action
geekyeggo/delete-artifact@v1 - deletes produced artifacts

Be sure to include the DEV usernames of your collaborators:

Matthew FoleyFollow

I write code for fun, and sometimes for work

How to lint PRs and welcome contributors using GitHub Actions

TED Vortex (Teodor Eugen Duțulescu) — Tue, 07 Dec 2021 08:07:30 +0000

Motivation

Expanding the @open-sauced ecosystem, it became tedious to apply all the necessary tooling available in open-sauced/open-sauced to newly created repositories and synchronising existing ones with minor updates.

Having github actions reusable workflows, we figured it would make a lot of sense to centralise our workflows and referencing them in other repositories.

The process was very simple and we want to showcase how to apply a similar process for your own organisation.

My Workflow

name: "Compliance"

on:
  pull_request_target:
    types:
      - opened
      - edited
      - synchronize

permissions:
  pull-requests: write

jobs:
  compliance:
    uses: open-sauced/open-sauced/.github/workflows/compliance.yml@main

The full workflow is available here: .github/workflows/compliance.yml

Submission Category: Maintainer Must-Haves

Yaml File or Link to Code

Live repository using this workflow:

open-sauced / conventional-commit

commit binary powered by commitizen with conventional commit standard

@open-sauced/conventional-commit

Never miss a conventional commit with commitizen running on npx.

📦 Install

This package is binary and doesn't require installation however you can add it to your repository as a devDependency:

npm install --save-dev @open-sauced/conventional-commit

🚀 Usage

All you have to do is run the script next to your package.json:

npx @open-sauced/conventional-commit
# or
npx conventional-commit

🔧 Configuration

The most common use case for this package is to run it instead of the git commit command inside your npm scripts:

{
  "scripts": {
    "push": "npx @open-sauced/conventional-commit"
  }
}

{
  "scripts": {
    "push": "npx conventional-commit"
  }
}

If you want to ensure local-only usage:

{
  "scripts": {
    "push": "conventional-commit"
  }
}

🤝 Contributing

We encourage you to contribute to Open Sauced! Please check out the Contributing guide for guidelines about how to proceed.

If…

View on GitHub

Yaml file link:
@open-sauced/open-sauced/.github/workflows/compliance.yml

Additional Resources / Info

Here are all the open source actions we are using to power this compliance workflow:

actions/first-interaction@v1 - welcomes first time contributors and invites them to @open-sauced discord
amannn/[email protected] - ensures pull request title matches conventional commits specification
mtfoley/[email protected] - check PR for compliance on title, linked issues, and files changed

Be sure to include the DEV usernames of your collaborators:

Matthew FoleyFollow

I write code for fun, and sometimes for work

Generate PDF handbook with Docusaurus using GitHub Actions

TED Vortex (Teodor Eugen Duțulescu) — Tue, 07 Dec 2021 08:04:29 +0000

Motivation

Having @open-sauced docs built using Docusaurus, we started exploring the plugin ecosystem and identified various improvements we could apply.

One of the community plugins we found during that process was signcl/docusaurus-prince-pdf, an npm package leveraging sindresorhus/got to crawl all the documentation and generate a PDF version.

Having a portable document generated as a downloadable release asset, we could more easily share the entirety of our docs and have that document available for offline use.

We faced the challenge of having to access the upcoming version during the deployment workflow, installing additional binaries, and deploying the generated asset as part of the release.

My Workflow

The full workflow is available here: .github/workflows/release.yml

In order to generate a handbook out of a Docusaurus instance we need to build the application in a container before uploading it as a build artifact for later workflow steps.

This is all taken care of in the new docker job that was created for the hackaton:

jobs:
  docker:
    name: Build container
    runs-on: ubuntu-latest
    steps:
      - name: "☁️ checkout repository"
        uses: actions/checkout@v2

      - name: "🔧 setup buildx"
        uses: docker/setup-buildx-action@v1

      - name: "🔧 cache docker layers"
        uses: actions/cache@v2
        with:
          path: /tmp/.buildx-cache
          key: ${{ runner.os }}-buildx-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-buildx-

      - name: "🔧 docker meta"
        id: meta
        uses: docker/metadata-action@v3
        with:
          images: ${{ github.repository }}
          tags: latest

      - name: "📦 docker build"
        uses: docker/build-push-action@v2
        with:
          context: .
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          outputs: type=docker,dest=/tmp/docker.tar
          push: false
          cache-from: type=gha, scope=${{ github.workflow }}
          cache-to: type=gha, scope=${{ github.workflow }}

      - name: "📂 docker artifacts"
        uses: actions/upload-artifact@v2
        with:
          name: docker
          path: /tmp/docker.tar

Concurrently, the build job prepares static npm assets and uploads them as an artifact for a subsequent job:

jobs:
  build:
    name: Build application
    runs-on: ubuntu-latest
    steps:
      - name: "☁️ checkout repository"
        uses: actions/checkout@v2

      - name: "🔧 setup node"
        uses: actions/[email protected]
        with:
          node-version: 16

      - name: "🔧 install npm@latest"
        run: npm i -g npm@latest

      - name: "📦 install dependencies"
        uses: bahmutov/npm-install@v1

      - name: "🚀 static app"
        run: npm run build

      - name: "📂 production artifacts"
        uses: actions/upload-artifact@v2
        with:
          name: build
          path: build

We then move to the release job, downloading all the artifacts and running our custom configuration @open-sauced/semantic-release-conventional-config from a docker socket:

jobs:
  release:
    environment:
      name: production
      url: https://github.com/${{ github.repository }}/releases/tag/${{ env.RELEASE_TAG }}
    name: Semantic release
    needs:
      - docker
      - build
    runs-on: ubuntu-latest
    steps:
      - name: "☁️ checkout repository"
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: "📂 download docker artifacts"
        uses: actions/download-artifact@v2
        with:
          name: docker
          path: /tmp

      - name: "📦 load tag"
        run: |
          docker load --input /tmp/docker.tar
          docker image ls -a

      - name: "📂 download build artifacts"
        uses: actions/download-artifact@v2
        with:
          name: build
          path: /tmp/build

      - name: "🚀 release"
        id: semantic-release
        uses: docker://ghcr.io/open-sauced/semantic-release-conventional-config:3.0.0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The next step is a little verbose, in order to crawl our docs website we need to:

mount the previously built container on port 8080
install Prince 14
run docusaurus-prince-pdf
deploy to static gh-pages

The deploy job is doing all the heavy lifting:

jobs:
  deploy:
    name: Deploy to static
    needs:
      - build
      - release
    runs-on: ubuntu-latest
    services:
      docs:
        image: ghcr.io/${{ github.repository }}:latest
        ports:
          - 8080:80
    steps:
      - name: "☁️ checkout repository"
        uses: actions/checkout@v2

      - name: "📂 download artifacts"
        uses: actions/download-artifact@v2
        with:
          name: build
          path: /home/runner/build

      - name: Install Prince
        run: |
          curl https://www.princexml.com/download/prince-14.2-linux-generic-x86_64.tar.gz -O
          tar zxf prince-14.2-linux-generic-x86_64.tar.gz
          cd prince-14.2-linux-generic-x86_64
          yes "" | sudo ./install.sh

      - name: "🔧 setup node"
        uses: actions/[email protected]
        with:
          node-version: 16

      - name: "🔧 install npm@latest"
        run: npm i -g npm@latest

      - name: "📦 install dependencies"
        uses: bahmutov/npm-install@v1

      - name: "📂 copy artifacts"
        run: cp -R /home/runner/build .

      - name: "🚀 generate pdf"
        run: npm run pdf

      - name: "🚀 deploy static"
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./build
          commit_message: ${{ github.event.head_commit.message }}
          enable_jekyll: false
          cname: docs.opensauced.pizza

As a final step, we need to clean up our build and docker artifacts, a simple but necessary step:

jobs:
  cleanup:
    name: Cleanup actions
    needs:
      - deploy
    runs-on: ubuntu-latest
    steps:
      - name: "♻️ remove build artifacts"
        uses: geekyeggo/delete-artifact@v1
        with:
          name: |
            build
            docker

Submission Category: DIY Deployments

Yaml File or Link to Code

Live repository using this workflow:

open-sauced / docs

OpenSauced documentation built with docusaurus

🍕 OpenSauced Docs 🍕

The path to your next Open Source contribution

🤝 Contributing

We encourage you to contribute to OpenSauced! All contributors are required to abide by our Code of Conduct. Please check out the Contributing guide for guidelines about how to proceed with your contribution.

🖥️ Development

npm ci
npm start

🍕 Community

Got Questions? Join the conversation in our Community.
Find OpenSauced videos and release overviews on our YouTube Channel.

⚖️ LICENSE

View on GitHub

Yaml file link:
@open-sauced/docs.opensauced.pizza/main/.github/workflows/release.yml

Additional Resources / Info

Here are all the open source actions we are using to power this release workflow:

actions/checkout@v2 - most performant git checkout
actions/[email protected] - we use it to set the node version to 16
actions/upload-artifact@v2 - we use it to transport our artifacts in between jobs
actions/download-artifact@v2 - we use it to download our artifacts in between jobs
docker/setup-buildx-action@v1 - we use it to set up the docker builder
actions/cache@v2 - we use it to cache docker layers
docker/metadata-action@v3 - we use it to normalize most of our docker container values
docker/build-push-action@v2 - we use it to build the container
bahmutov/npm-install@v1 - lightning-fast npm ci with built-in cache
open-sauced/semantic-release-conventional-config@v3 - semantic-release configuration, docker container and GitHub action
peaceiris/actions-gh-pages@v3 - deploys any folder(s) to gh-pages, can use it for multiple static endpoints
geekyeggo/delete-artifact@v1 - deletes produced artifacts

Be sure to include the DEV usernames of your collaborators:

Matthew FoleyFollow

I write code for fun, and sometimes for work