A workflow example
Welcome to my personal blog Torch-Fan

name: Build and Deploy to ACK

on:
  release:
    types: [created]

# Environment variables available to all jobs and steps in this workflow.
env:
  REGION_ID: cn-hangzhou
  REGISTRY: registry.cn-hangzhou.aliyuncs.com
  NAMESPACE: namespace
  IMAGE: repo
  TAG: ${{ github.sha }}
  ACK_CLUSTER_ID: clusterID
  ACK_DEPLOYMENT_NAME: nginx-deployment

  ACR_EE_REGISTRY: myregistry.cn-hangzhou.cr.aliyuncs.com
  ACR_EE_INSTANCE_ID: instanceID
  ACR_EE_NAMESPACE: namespace
  ACR_EE_IMAGE: repo
  ACR_EE_TAG: ${{ github.sha }}

jobs:
  build:
    runs-on: ubuntu-latest
    environment: production
    
    steps:
    - name: Checkout
      uses: actions/checkout@v2
    
    # 1.1 Login to ACR   
    - name: Login to ACR with the AccessKey pair
      uses: aliyun/acr-login@v1
      with:
        region-id: "${{ env.REGION_ID }}"
        access-key-id: "${{ secrets.ACCESS_KEY_ID }}"
        access-key-secret: "${{ secrets.ACCESS_KEY_SECRET }}"

1. YAML syntax of workflow:

• The syntax of workflow file is yaml syntax, which is based on yml or yaml as file suffix.
• Workflow files must be stored in your warehouse github/workflows directory

2. name

This field identifies the name of the workflow

If this field is empty, the name displayed by GitHub on the Actions page of the warehouse is the relative path from the root directory of the warehouse to the workflow file.

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsteps

3. on

Required

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#on

This field is used to indicate the GitHub event that triggered the workflow. This link can be seen for all GitHub events that can trigger the workflow: GitHub can trigger the event of workflow

• on
• on.<event_name>.types
• on.<push|pull_request>.<branches|tags>
• on.<push|pull_request>.paths
• on.schedule

For the pattern matching rules in GitHub Actions writing, please refer to: {% post_link GitHub Actions pattern matching rules%}

Here are some examples of triggering events:

on: push

on: [push, pull_request]

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration does not affect the page_build event above
      - created

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:    
      # Push events on main branch
      - main
      # Push events to branches matching refs/heads/mona/octocat
      - 'mona/octocat'
      # Push events to branches matching refs/heads/releases/10
      - 'releases/**'
      - '!release/**-alpha'  # The release/**-alpha branch will not be matched!, 
    # Sequence of patterns matched against refs/tags
    tags:        
      - v1             # Push events to v1 tag
      - v1.*   	       # Push events to v1.0, v1.1, and v1.9 tags

# Will not match the contents of tags or tags branches in the workflow when they are running
on:
  push:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      # Push events to branches matching refs/heads/mona/octocat
      - 'mona/octocat'
      # Push events to branches matching refs/heads/releases/beta/3-alpha
      - 'releases/**-alpha'
    # Sequence of patterns matched against refs/tags
    tags-ignore:
      - v1.*           # Push events to tags v1.0, v1.1, and v1.9

on:
  schedule:
    - cron: '30 5,17 * * *'

4. premissions

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#permissions

Using this field, you can limit GitHub_ Permission granted by token. This is a global permission setting, which will be applied to all tasks of the workflow. You can also add the permissions field for an individual task and set permissions separately

The following are the available fields, i.e. permission access values:

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  issues: read|write|none
  packages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

When you set permissions for some fields, the value of all fields without permissions is None

You can set all fields to be writable or readable using the following syntax:

permissions: read-all|write-all

5. env

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#env

Using this field, you can set a series of environment variables that can be used by jobs in the workflow. Of course, you can also set environment variables separately in the job. The environment variables set in the root node of the workflow file are global.

For example:

env:
  SERVER: production

6. defaults

Provide default settings for job

defaults:
	run:
		shell: bash
		working-directory: scripts

The above configuration configures the default shell and working directory for all job s

7. jobs

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobs

• A workflow contains several job s
• The execution of these jobs is parallel by default. If you need to execute jobs serially, you need to set jobs< job_ id>. Needs keyword
• The environment in which each job runs is specified by runs on

1. job.<job_id>

Every job must have an id associated with it_ id is a string, and its value is a map, which contains job related configuration data Each job_id should be unique job_id can only be expressed in Starts with a letter and can only contain Letters and-

For example:

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

2. job.<job_id>.name

job name displayed on GitHub

3. job.<job_id>.needs

Indicates which jobs must be completed before executing the job

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

4. job.<job_id>.runs-on

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on

Each job must specify a running environment. GitHub hosted runner types:

Virtual environment	YAML workflow label
Windows Server 2019	windows-latest or windows-2019
Windows Server 2016	windows-2016
Ubuntu 20.04	ubuntu-latest or ubuntu-20.04
Ubuntu 18.04	ubuntu-18.04
Ubuntu 16.04	ubuntu-16.04
macOS Big Sur 11.0	macos-11.0
macOS Catalina 10.15	macos-latest or macos-10.15

runs-on: ubuntu-latest

Of course, you can customize the environment, but it seems unnecessary in most cases. How to customize the environment

5. job.<job_id>.permissions

See global permissions

6. job.<job_id>.environment

Create an environment for github. github pages is an environment

I haven't used it for the time being. I'll learn more about it later

7. job.<job_id>.outputs

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idoutputs

The outputs of a job can be accessed by all jobs that depend on the job. If there is a key in the output, it will be modified and will not be sent to GitHub Actions

If you need to use the output of the dependent job, you can use the needs context

jobs:
  job1:
    runs-on: ubuntu-latest
    # Map a step output to a job output
    outputs:
      output1: ${{ steps.step1.outputs.test }}
      output2: ${{ steps.step2.outputs.test }}
    steps:
      - id: step1
        run: echo "::set-output name=test::hello"
      - id: step2
        run: echo "::set-output name=test::world"
  job2:
    runs-on: ubuntu-latest
    needs: job1
    steps:
      - run: echo ${{needs.job1.outputs.output1}} ${{needs.job1.outputs.output2}}

8. job.<job_id>.env

See global environment variables

9. job.<job_id>.defaults

See global default configuration

10. job.<job_id>.if

Using if, we can make the job run only when the condition of if is satisfied

Note that if you want to tell GitHub if to be treated as an expression instead of a string, you need to use: ${{< expression >}}$

Related expressions, operations and functions are visible: Operations and functions supported by GitHub

jobs:
  job1:
  job2:
    needs: job1
  job3:
    if: always()  # Whether job1 and job2 are executed successfully or not
    needs: [job1, job2]

Common functions are:

steps:
  ...
  - name: The job has succeeded 
    if: ${{ success() }}  # The steps before the step are successfully executed

if: ${{ always() }}  # Execute anyway (return true if the workflow is cancelled)

if: ${{ cancelled() }}  # Execute when workflow is cancelled

if: ${{ failure() }}  # If the previous fails, execute it again

11. job.<job_id>.steps

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idsteps

The content of steps is very rich. In order not to overlap with the documents, only the main parts are introduced here:

1. run

• Each command line instruction is executed using the shell of the operating system
• Each run can have a field name. If it is not specified, the name is the command corresponding to run
• Each run keyword corresponds to a new process. If there are multiple instructions in run, these instructions will be executed in the same shell

# single-line command
- name: Install Dependencies
  run: npm install

# multi-line command
- name: Clean install dependencies and build
  run: |  # Reserved newline of yaml
  	npm cli
  	npm run build

Working directory can specify the working path to execute instructions

- name: Clean temp directory
  run: rm -rf *
  working-directory: ./temp

steps:
  - name: Display the path
    run: echo ${env:PATH}
    shell: powershell

2. with

This field is used to pass parameters for Actions

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/hello_world@main
        with:
          first_name: Mona  # These are parameters
          middle_name: The
          last_name: Octocat    

When the Actions used are from the Docker container, the usage of with is as follows:

steps:
  - name: Explain why this job ran
    uses: monacorp/action-name@main
    with:
      entrypoint: /bin/echo
      args: The ${{ github.event_name }} event triggered this step.

When using with, the Action from docker has two fields, one is entrypoint and the other is args Args is the parameter passed to entrypoint. People who often use docker know that entrypoint is the executable path executed immediately when entering the container.

3. container

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer

Use and verification of containers

4. services

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idservices

Service usage (such as ngnix), configuration and verification