11 Powerful GitHub Actions Workflows

Struggling to automate your DevOps tasks? You’re not alone. Many teams spend countless hours on repetitive actions, time that could be used to craft more features. GitHub Actions workflows can change this. They allow you to automate almost every part of your development process, from testing to deployment. Let’s look at some powerful workflows you can use to make your life easier.

What are GitHub Actions Workflows?

GitHub Actions workflows are automated processes you can define in your GitHub repository. These workflows can respond to events like code pushes, pull requests, or even schedules. A workflow is made up of one or more jobs, and each job can have a series of steps.

These actions can perform tasks as basic as running unit tests to complex tasks like deploying your code to a cloud provider. The beauty of GitHub Actions is in its flexibility, you can mix and match pre-built actions or use custom scripts to achieve what you need.

Why Use GitHub Actions Workflows?

Think of GitHub Actions workflows as a personal assistant for your development process. They handle the boring stuff, leaving you free to work on the important tasks, plus the advantages are more than just saving time.

• Automation: Automating builds, tests, and deployments reduces manual errors. It also ensures consistency in your process.
• Speed: Workflows run in parallel, which speeds up your development lifecycle. Feedback comes faster, and the time from code to production is shorter.
• Integration: GitHub Actions integrates seamlessly with other GitHub features and many other services.
• Customization: Build custom actions if what you need isn’t available on the marketplace.
• Cost-Effective: GitHub provides free minutes for public repositories. This makes it an affordable option for many projects.
• Improve quality: You get quality with automation. Test automation is key here. Code gets tested every time something changes.
• Focus on code: With the automated workflow, developers can focus on writing code. They can stop worrying about the deployment steps.

11 Powerful GitHub Actions Workflows

Here are 11 workflows that will help level up your DevOps.

1. Continuous Integration (CI) Workflow

Continuous Integration is the base of modern development. A CI workflow will test your code every time you push changes to a repository. It is the first step to detect problems early, before they cause chaos down the line.

This workflow has the basic steps for a CI process.

• It will trigger on any push to your main branch or any pull request.
• The workflow checks out your code and sets up Node.js.
• It installs dependencies, runs linters, and tests your code.
• If all steps pass, your code is good for integration.

name: CI

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18

      - name: Install dependencies
        run: npm ci

      - name: Run linters
        run: npm run lint

      - name: Run tests
        run: npm run test

How to use it:

• Create a new file in your repository named .github/workflows/ci.yml.
• Copy the above code into that file.
• Change the node-version to match your setup.
• Make sure the npm run scripts in the run steps match your project.
• Commit your file and push it. Your workflow will now trigger on pushes and pull requests.

2. Continuous Deployment (CD) Workflow

Continuous Deployment goes one step further than CI. It pushes changes to production after the tests have passed. This automates code deployment, so you release features faster.

Here is an example of a CD workflow.

• It triggers on pushes to the main branch after tests have passed.
• It sets up Node.js and builds the project.
• It uses scp command to deploy files to the server.
• The workflow also runs a remote script to restart the server.

name: CD

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: [build]

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18

      - name: Install dependencies
        run: npm ci

      - name: Build project
        run: npm run build

      - name: Deploy to server
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.DEPLOY_HOST }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.DEPLOY_KEY }}
          source: build
          target: /var/www/my-app

      - name: Restart server
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.DEPLOY_HOST }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.DEPLOY_KEY }}
          script: |
            pm2 restart my-app

How to use it:

• Add this code to a new file .github/workflows/cd.yml.
• Set up secrets for DEPLOY_HOST, DEPLOY_USER, and DEPLOY_KEY in your repository settings.
• Change the build script and deployment path as needed.
• Push the file. Code pushed to main branch will get deployed.

3. Docker Image Build and Push Workflow

Docker makes packaging and sharing applications easy. With a Docker workflow, you can automate the build and push of Docker images to a container registry.

The workflow does the following:

• Triggers on pushes to the main branch.
• It logs in to the Docker registry.
• It builds and tags the Docker image.
• It pushes the Docker image to the registry.

name: Docker Build and Push

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Log in to Docker registry
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and tag Docker image
        uses: docker/build-push-action@v3
        with:
          context: .
          push: false
          tags: ghcr.io/${{ github.repository }}:latest

      - name: Push Docker image
        run: docker push ghcr.io/${{ github.repository }}:latest

How to use it:

• Create a new file .github/workflows/docker.yml.
• Copy the above code into that file.
• Make sure ghcr.io matches your registry.
• Push the file, changes to main branch trigger a build.

4. Scheduled Workflow for Regular Tasks

Not all workflows run on code pushes or pull requests. You can use schedules to run tasks periodically. This is great for maintenance, data analysis, and other regular jobs.

This scheduled workflow is simple.

• It triggers once a day at midnight UTC.
• It runs a script that prints a timestamp.

name: Scheduled Task

on:
  schedule:
    - cron: '0 0 * * *'

jobs:
  task:
    runs-on: ubuntu-latest
    steps:
      - name: Run task
        run: date

How to use it:

• Create .github/workflows/scheduled.yml.
• Paste the code.
• Change the cron expression to meet your needs.
• Replace the date command with your real task.

5. Issue Management Workflow

You can use a workflow to manage issues. This can make it easy to create labels or assign people to new issues, streamlining the triage process.

This workflow does a few things.

• It triggers when a new issue is opened.
• It adds a label and assigns it to the issue creator.

name: Issue Management

on:
  issues:
    types: [opened]

jobs:
  manage:
    runs-on: ubuntu-latest
    steps:
      - name: Add label
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.issues.addLabels({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              labels: ["needs-triage"]
            })

      - name: Assign to creator
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.issues.addAssignees({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              assignees: [context.issue.user.login]
            })

How to use it:

• Create .github/workflows/issue-management.yml.
• Copy the code.
• Change the labels or assignments as you need.

6. Pull Request Review Workflow

Automated checks on pull requests will help ensure that code is up to standard. This workflow does a few things.

• It triggers on pull requests to the main branch.
• It requests a review from a specific user or team.

name: Pull Request Review

on:
  pull_request:
    branches:
      - main

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - name: Request review
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.pulls.requestReviewers({
              owner: context.repo.owner,
              repo: context.repo.repo,
              pull_number: context.issue.number,
              reviewers: ["octocat"]
            })

How to use it:

• Create a file named .github/workflows/pr-review.yml.
• Paste in the code above.
• Change the reviewers as needed.

7. Static Code Analysis Workflow

Static code analysis will help you find code problems before running the code. This improves the quality of your code and helps you avoid errors down the line.

This workflow runs a static analysis tool on every push.

• Triggers on pushes to the main branch or any pull request.
• It checks out the code and sets up Python.
• It installs and runs the static analysis tool.

name: Static Analysis

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  analyze:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'

      - name: Install tool
        run: pip install pylint

      - name: Run analysis
        run: pylint my_code.py

How to use it:

• Create .github/workflows/static-analysis.yml.
• Paste the code.
• Change the Python version and analysis command to what you need.

8. Website Monitoring Workflow

This workflow is for anyone who has a website they want to check on. This will allow you to verify if the site is up and working. You can set this to notify you if a website is down.

This workflow is simple:

• It triggers on a schedule.
• It checks if a web site is available.
• Sends an email if the site is not working.

name: Website Monitoring

on:
  schedule:
    - cron: '0 * * * *'

jobs:
  monitor:
    runs-on: ubuntu-latest
    steps:
      - name: Check website
        uses: jtalk/url-health-check-action@v3
        id: health
        with:
          url: 'https://example.com'
          max-attempts: 3
          retry-wait: 3

      - name: Send email if not available
        if: steps.health.outputs.status != 'available'
        uses: dawidd6/action-send-email@v3
        with:
            to: [email protected]
            from: [email protected]
            subject: Website down!
            body: 'The website is not available at ${{ steps.health.outputs.time }}'
            server_address: smtp.example.com
            server_port: 587
            username: ${{secrets.MAIL_USER}}
            password: ${{secrets.MAIL_PASSWORD}}
            secure: true

How to use it:

• Create .github/workflows/monitor.yml.
• Paste the code above.
• Change the url to your website.
• Set the to, from, server_address and server_port to your needs.
• Set up MAIL_USER and MAIL_PASSWORD as secrets.

9. Branch Protection Workflow

Branch protection rules can be enforced using GitHub actions. This will make sure only approved code makes it into your primary branches.

This workflow will do the following.

• It triggers on pull requests to the main branch.
• It requires that a review is done before merging.

name: Branch Protection

on:
  pull_request:
    branches:
      - main

jobs:
  protection:
    runs-on: ubuntu-latest
    steps:
      - name: Require review
        uses: actions/github-script@v6
        with:
          script: |
             github.rest.pulls.requestReviewers({
              owner: context.repo.owner,
              repo: context.repo.repo,
              pull_number: context.issue.number,
              reviewers: ["octocat"],
              required_approving_review_count: 1
            })

How to use it:

• Create .github/workflows/branch-protection.yml.
• Copy the code.
• Change the reviewers and required_approving_review_count to suit your needs.

10. Database Backup Workflow

Regular backups are key to avoid data loss. This workflow will help you to backup your database in an automatic way.

Here’s a simple workflow for backups:

• It triggers on a schedule.
• It uses an action to connect to a database, dump it, and upload to a storage service.

name: Database Backup

on:
  schedule:
    - cron: '0 0 * * *'

jobs:
  backup:
    runs-on: ubuntu-latest
    steps:
      - name: Backup database
        uses: elgohr/[email protected]
        with:
          mysql_host: ${{ secrets.DB_HOST }}
          mysql_database: ${{ secrets.DB_NAME }}
          mysql_user: ${{ secrets.DB_USER }}
          mysql_password: ${{ secrets.DB_PASSWORD }}
          s3_bucket: ${{ secrets.S3_BUCKET }}
          s3_access_key: ${{ secrets.S3_ACCESS_KEY }}
          s3_secret_key: ${{ secrets.S3_SECRET_KEY }}
          s3_region: ${{ secrets.S3_REGION }}

How to use it:

• Create .github/workflows/db-backup.yml.
• Copy in the code.
• Set secrets for database and S3 details in your repository settings.

11. Release Management Workflow

Managing releases can be complex. This workflow makes it easier to tag releases and creates release notes.

Here is what it will do:

• Triggers on pushes to a specific branch.
• It sets up Node.js.
• It runs a script to create a new tag and release note.

name: Release Management

on:
  push:
    branches:
      - release

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18

      - name: Create release
        run: |
          VERSION=$(date +'%Y.%m.%d')
          git tag -a "v$VERSION" -m "Release v$VERSION"
          git push origin "v$VERSION"
          echo "::set-output name=release_version::v$VERSION"
        id: create_release

      - name: Create release notes
        uses: actions/github-script@v6
        with:
          script: |
            const { release_version } = context.payload.outputs
            github.rest.repos.createRelease({
              owner: context.repo.owner,
              repo: context.repo.repo,
              tag_name: "${{ steps.create_release.outputs.release_version }}",
              name: "Release ${{ steps.create_release.outputs.release_version }}",
              body: "Release notes here"
            })

How to use it:

• Create a new file named .github/workflows/release.yml.
• Paste the code into the file.
• Change the branch name, set up git if needed.
• Add anything extra to the release process.

Best Practices for GitHub Actions Workflows

While the above workflows are useful, keeping a few best practices in mind is important.

• Keep workflows simple: Break down complex tasks into smaller jobs that are easy to debug and maintain.
• Use secrets: Store sensitive data like passwords and API keys as secrets and avoid hardcoding in your workflows.
• Version your actions: Always pin actions to a specific version and do not use latest. This keeps workflows consistent.
• Use reusable workflows: If you find yourself repeating workflows, consider creating reusable workflows.
• Test workflows: Test all of your workflows thoroughly. Make sure they behave as expected.
• Document: Explain every step and its purpose. Make the workflows easy for your team to understand.

Debugging GitHub Actions Workflows

Sometimes workflows don’t go as planned. Here’s how to fix that:

• Check logs: Review the output logs for any errors or issues.
• Add debug statements: Use echo commands to add logs. This will make it easier to see what is going on.
• Use workflow dispatch: Trigger the workflows by hand with different inputs to test.
• Simplify: Break down complex workflows into smaller steps for testing.
• Search for solutions: There are a ton of posts and online resources to help.

Taking Your Workflows Further

GitHub Actions workflows are a base. You can add many more tools or steps. Here are a few ideas:

• Notifications: Use workflows to send alerts to Slack, emails, or other services when builds fail.
• Cloud deployments: Integrate workflows with cloud providers such as AWS, Azure, or GCP for automated deployments.
• Security scanning: Add steps to check code for vulnerabilities before merging.
• Custom actions: Build custom actions to suit specific needs if no actions exist.

Start Automating Today

GitHub Actions Workflows are a good way to level up your development. These 11 examples provide a good place to start. You can use these as is or combine them. With automation, you improve quality and focus more on building amazing software. You just need to start.