The source code for this blog is available on GitHub.
Note
Top

Github Action

Cover Image for Github Action
Han Chen
Han Chen

CI and Github Action

CI Tools

Here are some popular Continuous Integration (CI) tools:

  1. Jenkins: Jenkins is an open-source CI tool widely used for automating the building, testing, and deployment of software projects. It offers extensive plugin support and has a large community contributing to its ecosystem.
  2. Travis CI: Travis CI is a cloud-based CI tool primarily designed for open-source projects. It supports a wide range of programming languages and provides easy integration with popular version control systems like GitHub.
  3. CircleCI: CircleCI is a cloud-based CI/CD platform that offers continuous integration and deployment capabilities. It supports various programming languages, provides easy configuration, and integrates with popular source code repositories.
  4. GitLab CI/CD: GitLab CI/CD is part of the GitLab platform, providing built-in CI/CD capabilities. It allows you to define pipelines using a YAML-based configuration file and provides a comprehensive DevOps solution with integrated source code management, issue tracking, and more.
  5. Bamboo: Bamboo is a CI/CD tool developed by Atlassian. It offers robust integration with other Atlassian products like Jira and Bitbucket. Bamboo supports continuous integration, automated builds, and release management.
  6. GitHub Actions: GitHub Actions is a CI/CD platform tightly integrated with GitHub. It allows you to automate workflows directly within your repositories using YAML-based configuration files. GitHub Actions provides flexibility, scalability, and seamless integration with the GitHub ecosystem.
  7. TeamCity: TeamCity is a powerful CI tool developed by JetBrains. It offers a wide range of features and supports multiple programming languages. TeamCity has a user-friendly interface, extensive integration capabilities, and can be easily configured to meet complex build and deployment requirements.

GitHub Actions

GitHub Actions is a platform for automating your software development workflows, directly on the GitHub platform. It provides a way to automate tasks such as building, testing, and deploying code, as well as more complex workflows, such as continuous integration and continuous deployment (CI/CD). With GitHub Actions, you can run your software development process in a simple, consistent, and scalable manner, all within the GitHub ecosystem. GitHub Actions supports multiple programming languages and platforms, so it can be used with a wide range of projects, regardless of the technology stack being used.

How can I use github-runner

GitHub Actions run on the GitHub Actions virtual machine (VM) and can be used to automate a wide range of tasks such as building, testing, and deploying code. To use GitHub Actions, you first need to set up a GitHub Actions workflow. A workflow is a set of automated steps that perform a specific task. The steps in a workflow can be triggered by a variety of events, such as a push to a specific branch or a new release.

GitHub Runners are the components of GitHub Actions that run the tasks defined in a workflow. When you trigger a workflow, GitHub sends the task to a runner, which performs the actions specified in the workflow. GitHub provides hosted runners for Linux, Windows, and macOS, so you don't need to set up and manage your own runners. However, if you prefer, you can also use self-hosted runners.

To use GitHub Runners, you'll need to create a GitHub Actions workflow and specify the tasks you want the runner to perform. Once you've created the workflow, you can trigger it manually or automatically based on a specific event, such as a push to a branch.

How can i specify the tasks I want the runner to perform

You can specify the tasks you want the GitHub Actions runner to perform by defining a workflow in a YAML file stored in your GitHub repository. The workflow file should be named main.yml and should be stored in the .github/workflows directory. In the workflow file, you can define the steps that the runner should take by using the actions provided by the GitHub Actions marketplace, or you can write your own custom actions using code. Each step in the workflow is defined as a separate task, and you can use conditionals, loops, and other constructs to control the flow of the workflow and make it flexible and customizable. The workflow file should be committed to your repository, and the runner will automatically detect and execute the workflow whenever an event occurs that triggers the workflow.

The .github/workflows directory is located in your own Github project repository. This is where you can create and manage your Github Actions workflows. Each workflow is defined in a separate YAML file in this directory, and the workflows are triggered based on events that occur within your Github project, such as pushes to the repository, pull request creation, or release creation.

How can i put multiple tasks in .github/workflows

You can put multiple tasks in .github/workflows by defining multiple jobs in your workflow file. Each job can have multiple steps, and the steps can run concurrently or sequentially, depending on your needs.

Github action example

In this example, the workflow has two jobs: "build" and "deploy". The "build" job runs whenever a push is made to the repository, and performs a series of tasks, including checking out the code, setting up Node.js, installing dependencies, and running tests. The "deploy" job also runs whenever a push is made, and performs a deployment.

name: CI/CD Workflow

on: push

jobs:
  build:
    runs-on: ubuntu-latest

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

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

    - name: Install dependencies
      run: |
        npm ci

    - name: Test
      run: |
        npm test
    
  deploy:
    runs-on: ubuntu-latest

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

    - name: Deploy
      run: |
        # Your deployment commands here

You can add as many jobs as you need to your workflow, and each job can have as many steps as you need.

In the context of Github Actions, the "uses" keyword is used to specify a particular action that should be run as part of a workflow. An action is a pre-written piece of code that performs a specific task, such as running tests or deploying to a production environment. The "uses" keyword is followed by the name of the action that should be run, along with any required inputs and parameters. For example:

steps:
- name: Run tests
  uses: actions/run-tests@v1
  with:
    env: TEST_SUITE=unit

In this example, the "uses" keyword specifies the "actions/run-tests@v1" action should be run, and the "with" keyword provides additional inputs to the action, such as the environment variables that should be set for the test run.

A simplist example

The following is the example github action config file

name: Print the environment variables

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [ 14.x, 16.x, 18.x, 20.x ]

    steps:
      - name: Print Discord settings
        env:
          DISCORD_CLIENT_ID: ${{ secrets.DISCORD_CLIENT_ID }}
          DISCORD_CLIENT_SECRET: ${{ secrets.DISCORD_CLIENT_SECRET }}
        run: echo "DISCORD VARIABLES 👉CLIENT_ID=$DISCORD_CLIENT_ID & SECRET=$DISCORD_CLIENT_SECRET"

      - name: Log environment variables
        run: |
          echo "GITHUB_REPOSITORY: ${{ env.GITHUB_REPOSITORY }}"
          echo "GITHUB_ACTOR: ${{ env.GITHUB_ACTOR }}"

name: Secondary Push Actions

on:
  push:
    branches-ignore:
      - main
      - production
      - develop
  pull_request:
    branches-ignore:
      - main
      - production
      - develop

jobs:
  test:
    runs-on: ubuntu-latest
    env:
      VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
      VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
      VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}

    steps:
      - uses: actions/checkout@v2

      - name: Test using Node.js
        uses: actions/setup-node@v1
        with:
          node-version: '18'
      - run: |
          echo "Skip build..."

      - name: Deploy to Vercel
        run: |
          if [[ "${{ github.ref }}" == "refs/heads/production" ]]; then
            echo "Deploying to Production..."
        
            curl -X POST https://api.vercel.com/v6/projects \
                  -H "Authorization: Bearer ${{ secrets.VERCEL_TOKEN }}" \
                  -H "Content-Type: application/json" \
                    -d '{
                    "name":"hyte",
                    "gitRepository":{
                      "repo": "iBuypowerUS/HYTE",
                      "type": "github",
                      "url":"https://github.com/iBuypowerUS/HYTE.git",
                      "ref":"production",
                      "path":"/",
                      "projectId": "${{ secrets.VERCEL_PROJECT_ID }}"
                    }
                  }'
          else
            echo "Deploying to Development..."
            npx vercel --token ${{ secrets.VERCEL_TOKEN }}
          fi

Github action for HYTE

Align Branches feature and checkout to delvelop

name: Align Branches (Develop)

on:
  push:
    branches:
      - develop

jobs:
  update_branches:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Setup Git
        run: |
          git config --global user.name "GitHub Action"
          git config --global user.email "action@github.com"

      - name: Update feature branch
        run: |
          git checkout feature
          git merge origin/develop
          git push origin feature

      - name: Update checkout branch
        run: |
          git checkout checkout
          git merge origin/develop
          git push origin checkout -f

This snippet is a configuration file written in YAML syntax for a GitHub Actions workflow. It defines a workflow named "Align Branches (Develop)" that will be triggered when there are push events to the "develop" branch.

Let's break down the structure and explain each section:

  • name: Align Branches (Develop): This is the name of the workflow, which helps identify it in the GitHub Actions dashboard or logs.
  • on:: This section defines the trigger event for the workflow. In this case, it is set to push, indicating that the workflow will be triggered when there are pushes to the repository.
    • push:: This further specifies that the workflow should trigger on push events.
    • branches:: Specifies the branches that will trigger the workflow. In this case, the workflow will run when there are pushes to the "develop" branch.
  • jobs:: This section defines the jobs that will be executed as part of the workflow.
    • update_branches:: The name of the job, in this case, "update_branches".
    • runs-on: ubuntu-latest: Specifies the operating system environment (Ubuntu) on which the job will run.
    • steps:: This section contains a series of steps to be executed as part of the job.
    • name: Checkout Repository: A step that checks out the repository, allowing subsequent steps to operate on its content.
    • uses: actions/checkout@v2: Specifies the GitHub Action to use for checking out the repository.
    • with:: Additional configuration options for the actions/checkout action.
    • fetch-depth: 0: Configures the depth of fetching history, setting it to 0 to fetch all history.
    • name: Setup Git: A step that sets up Git configuration for the subsequent Git operations.
  • run: |: Defines a multi-line shell command to be executed.
  • git config --global user.name "GitHub Action": Sets the global Git configuration for the user name to "GitHub Action".
  • git config --global user.email "action@github.com": Sets the global Git configuration for the user email to "action@github.com".
  • name: Update feature branch: A step that updates the "feature" branch by merging the latest changes from the "develop" branch and pushing the changes to the "feature" branch.
  • name: Update checkout branch: A step that updates the "checkout" branch in a similar manner, merging changes from the "develop" branch and pushing the changes to the "checkout" branch.

Each step in the workflow performs a specific action, such as checking out the repository, configuring Git, and updating branch(es) by merging changes from the "develop" branch.

Please note that this explanation provides an overview of the workflow's purpose and steps but does not cover any specific business logic or application context that the workflow might be intended for.

Align Branches feature and checkout to production

name: Align Branches (Production)

on:
  push:
    branches:
      - main

jobs:
  update_branches:
    runs-on: ubuntu-latest
    env:
      VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
      VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PRODUCTION_PROJECT_ID }}
      VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v2
        with:
          fetch-depth: 0

      - name: Setup Git
        run: |
          git config --global user.name "GitHub Action"
          git config --global user.email "action@github.com"

      - name: Update production branch
        run: |
          git checkout production
          git reset --hard origin/main
          git push origin production

      - name: Test using Node.js
        uses: actions/setup-node@v1
        with:
          node-version: '18'
      - run: |
          echo "Skip build..."

      - name: Deploy to Vercel
        run: |
          echo "Deploying to Product Replica..."
          npx vercel --token ${{ secrets.VERCEL_TOKEN }}  --prod

Deploy to production.hyte.com

name: Production Branch

on:
  push:
    branches:
      - production
  pull_request:
    branches-ignore:
      - production

jobs:
  deploy-to-production:
    runs-on: ubuntu-latest
    env:
      VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
      VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PRODUCTION_PROJECT_ID }}
      VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}

    steps:
      - uses: actions/checkout@v2

      - name: Test using Node.js
        uses: actions/setup-node@v1
        with:
          node-version: '18'
      - run: |
          echo "Skip build..."

      - name: Deploy to Vercel
        run: |
          echo "Deploying to Product Replica..."
          npx vercel --token ${{ secrets.VERCEL_TOKEN }}  --prod
HYTE Logo

Topics

Support

Workshop

© 2024 WOOTHINK. All Rights Reserved.
Site MapTerms and ConditionsPrivacy PolicyCookie Policy