Concepts, common use cases and examples of GitHub Actions

GitHub Actions in GitHub is a platform for continuous integration and continuous delivery. It can help you verify your code through automated builds (including compilation, release, and automated testing) to detect integration errors as soon as possible. Github was fully opened to this feature after November 2019, and now all github users can use this feature directly. GitHub provides Linux, Windows, and macOS virtual machines to run your workflow, or you can host your own self-hosted runner in your own data center or cloud infrastructure.

GitHub Actions enable developers to perform various tasks automatically in their code repositories. Whether it is automatically building and testing code, or automatically deploying applications, GitHub Actions can help development teams improve efficiency and reduce error rates. In this article, we will gain insight into the concepts, common use cases, and examples of GitHub Actions, and provide relevant reference documentation.

GitHub Actions Concepts and Terms

1. Workflow: Workflow is a process of automated tasks. It can be triggered and run in the GitHub repository, allowing developers to define automated processes of code based on their needs.
2. Action: Actions are scripts or commands that perform specific tasks. It can be a single task or a collection of tasks that are used to perform specific operations in a workflow, such as build, test, deployment, etc.
3. Event: Events refer to specific activities that occur in the GitHub repository, such as pushing code, creating pull requests, publishing versions, etc. These events can act as triggers for workflows, and when events occur, the corresponding workflow will be triggered to be executed.
4. Runner: The runner is a virtual environment or physical machine used to perform tasks in a workflow. GitHub provides managed runners and supports self-hosted runners, and developers can select the right runners to perform their workflows as needed.

Limitations of Github Actions

There are the following restrictions when using the free version of Github Action:

Job Execution Time - Each job in the workflow can run up to 6 hours of execution time. If the job reaches this limit, the job will terminate and cannot be completed.

Workflow Runtime - Each workflow run is limited to 35 days. If the workflow run reaches this limit, the workflow run will be cancelled. This period includes the execution duration and the time taken to wait and approval.

API Requests - You can perform up to 1000 API requests across all operations in the repository in one hour. If this limit is exceeded, other API calls will fail, which may cause the job to fail.

Concurrent Jobs - The number of concurrent jobs that can be run in an account depends on the GitHub plan, as shown in the following table. If it is exceeded, any other job will be queued.

Job Matrix - Job Matrix can generate up to 256 jobs per workflow run. This limitation applies to GitHub-hosted and self-hosted runners.

Workflow Run Queue - Queuing intervals per repository are no more than 500 workflow runs, with 10 seconds intervals. If the workflow run reaches this limit, the workflow run will terminate and cannot be completed.

What is Yaml?

When writing GithubActions processes, you need to create a workflow workflow. Workflow must be stored in the .github/workflows directory under the root path of your project library. Each workflow corresponds to a specific .yml file (or .yaml).
yml is a file in the YAML (YAML Ain’t Markup Language) language. It is data-centric and is more suitable for configuration files than properties, xml, etc. It has the following main characteristics:

Case sensitive.
Use indentation to represent hierarchical relationships.
Indentation can only use spaces, not TAB characters.
The number of indented spaces does not matter, as long as elements with the same level are left aligned.
‘#’ means comment.

Common Use Cases and Examples

Automatic build and test

This is a common use case where the workflow is automatically triggered to build and test the code when it is pushed to the repository.

name: Build and Test
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v2
    - name: Build
      run: make build
    - name: Test
      run: make test<

Automatic deployment to server

Another common use case is to automatically deploy applications to the server when a new version is released.

name: Deploy
on:
  release:
    types: [published]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout code
      uses: actions/checkout@v2
    - name: Deploy to server
      uses: easingthemes/ssh-deploy@v2
      with:
        server_ip: ${{ secrets.SERVER_IP }}
        server_port: ${{ secrets.SERVER_PORT }}
        username: ${{ secrets.SERVER_USERNAME }}
        password: ${{ secrets.SERVER_PASSWORD }}
        source: 'dist/'
        target: '/var/www/myapp'<

Push to Amazon ECR and Alibaba Cloud Container Registry (ACR)

This example shows how to build code into a Docker image and push it to Amazon ECR and Alibaba Cloud Container Registry (ACR).

name: Push to ECR and ACR
on:
  push:
    branches:
      - main
jobs:
  push_to_ecr:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2
        with:
          registry: ${{ secrets.AWS_REGISTRY_URL }}
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      - name: Build and push Docker image
        id: build-image
        run: |
          docker build -t ${{ secrets.AWS_REGISTRY_URL }}/my-image .
          docker push ${{ secrets.AWS_REGISTRY_URL }}/my-image
  push_to_acr:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Login to Alibaba Cloud
        uses: aliyun/login-action@v1
        with:
          access-key-id: ${{ secrets.ALIYUN_ACCESS_KEY_ID }}
          access-key-secret: ${{ secrets.ALIYUN_ACCESS_KEY_SECRET }}
          region: ${{ secrets.ALIYUN_REGION }}
      - name: Build and push Docker image
        id: build-image-acr
        run: |
          docker build -t ${{ secrets.ACR_REGISTRY_URL }}/my-image .
          docker login -u ${{ secrets.ACR_REGISTRY_USERNAME }} -p ${{ secrets.ACR_REGISTRY_PASSWORD }} ${{ secrets.ACR_REGISTRY_URL }}
          docker push ${{ secrets.ACR_REGISTRY_URL }}/my-image<

Summarize

The above are concepts, common use cases, and examples of GitHub Actions. By leveraging this capability, development teams can achieve more efficient development processes, improve code quality and deployment speed. If you have any questions about GitHub Actions, feel free to ask us!

This is the end of this article about the concepts, common use cases and examples of GitHub Actions. For more information about common use cases of GitHub Actions, please search for my previous articles or continue browsing the related articles below. I hope you will support me in the future!