Github Action is a Github based continuous integration service. It provides a server instance that allows one or more commands to be executed through actions, such as fetching code, running tests, logging into remote servers, publishing projects, etc.

Lot of

  1. Workflow: Each integration service that needs to run separately is a Workflow

  2. Job: A workflow consists of one or more Jobs. A workflow is a continuous integrated operation that can complete multiple tasks.

  3. Step: Each job consists of multiple steps.

  4. Action: Each step can execute one or more commands (actions) in turn.

Git Action file – Workflow

The github Actions configuration file is a Workflow file stored in the.gihub/workflows directory in the repository.

Workflow can create more than one as required. The Workflow specification uses the YAML format. The file name can be arbitrary depending on the functionality of the integration service, but the suffix must be.yml. GitHub automatically runs the.github/workflows files whenever it finds them.

Common Workflow configuration fields

name

The name of Workflow. If omitted, this defaults to the file name of the current Workflow file.

name: GitHub Actions Demo
Copy the code

on

Define the Git hooks that trigger the event. This can be a single hook name or multiple hooks

Trigger event when # push
on:push

Both push and pull start events
on: [push.pull_request]
Copy the code

When defining events, you can also qualify branches and labels

on:
  push:
    branches:
      - master
    
Copy the code

jobs

The body of the Workflow file is the Jobs field, which represents one or more tasks to be executed.

In the Jobs field, specify the job_id of each task. The specific name can be customized. The name field in job_id is a description of the job.

jobs:
  # define the first task
  my_first_job:
    name: My first job
  
  # second task defined
  my_second_job:
    name: My second job
Copy the code

Jobs.

. Needs NEEDS specifies the dependencies of the current task, that is, the order in which it is run.

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1.job2]
Copy the code

In the code above, Job1 must complete before joB2, while Job3 waits for job1 and joB2 to complete before running. Thus, the workflow runs in job1, joB2, and job3.

Jobs.

. The runs-on runs-on field specifies the VM environment required for running.

Ubuntu -latest, ubuntu-18.04 or Ubuntu-16.04

Windows-latest, Windows-2019 or Windows-2016

MacOS - latest or macOS 10.14
Copy the code

jobs.<job_id>.steps

The Steps field specifies the steps to run for each Job and can contain one or more steps. Each step can specify the following three fields.

Jobs.
      
       .steps.name: indicates the step name.
      
Jobs.
      
       .steps.run: command to run this step.
      
Jobs.
      
       .steps.use: this step runs
       The action.
Jobs.
      
       .steps.env: Environment variable required for this step.
      
Copy the code

Each step must have a run or an action

A complete Workflow file looks like this:

. github/workflows/main.yml

name: first github action workflow
on:
  push:
    branches:
      - master

jobs:
  first-job:
    name: my first job demo
    runs-on: ubuntu-latest
    steps:

    - name: first-action
      run:  | echo hello worldCopy the code

Using environment variables

There are two ways to configure environment variables:

  1. Define variables and their values directly in env, using $XXX.
# Here is one of the steps

  - Name: env-demo
    env:
      FIRSTNAME: hello
      LASTNAME: world
    run: | echo $FIRSTNAME $LASTNAMECopy the code
  1. Set the variable XXX by Secrets in the project, and obtain it by ${{XXX}} in the configuration. This variable definition applies to situations where private data is involved.

# Here is one of the steps

  - Name: env-demo
    env:
      FIRSTNAME: hello
      LASTNAME: world
    run: | echo $ACCESS_TOKENCopy the code

Implement the automatic deployment process

  1. The statementworkflowName, event trigger configuration.
  2. configurationjobName, dependent environment.
  3. stepsConfiguration.

Using the React project as an example, steps should be configured as follows:

Deploy the project to the GitHub Pages configuration

name: github actions build and deploy gh-pages
on:
  push: 
    branches:
      - master
jobs:
  build_and_deploy:
    runs-on: ubuntu-latest

    steps:
       # 1. Get the source code, where you need to check out the repository code into the virtual machine instance
      - name: Checkout 🛎 ️
        uses: The actions/[email protected]
        with:
        If you are using Actions /checkout@v2, in most cases you must set persistent credentials to false for the deployment to work correctly
          persist-credentials: false
      
      Install and build dependencies in the React project
      - name: Install and Build 🔧
        run: | npm install npm run build        
      # 3. Deploy packaged code to the GH-Pages branch
      - name: Deploy 🚀
        uses: JamesIves/[email protected]
        with:
          # In order for GitHub to trigger a rebuild page, you must use the GitHub token provided by the repository to provide the action. GITHUB_TOKEN is provided by the system by default and does not require a separate configuration of environment variables
          GITHUB_TOKEN: The ${{ secrets.GITHUB_TOKEN }}
          BRANCH: gh-pages 
          FOLDER: dist 
Copy the code

Deploy the project to a private server

The steps to deploy the project to a private server are similar to the steps to deploy GH-Pages, except that we need to configure more environment variables to match the server login. Use ssh-deploy Action to deploy the private server.

Ssh-deploy Parameter description:

  1. SSH_PRIVATE_KEY.required

Ssh-deploy Logs in to the remote server using SSH. Configure the private key corresponding to a public key record stored in the ~/. SSH /authorized_keys file on the remote server. This configuration must be correct, otherwise the Github action will not enter the server.

If the authorized_keys file does not exist on the server, or there is no record in the file, you can create a new authorized_keys file and add a local computer’s public key information to the file.

Method to add the local public key to the server authorized_keys

  ssh-copy-id user@host  # user@host User name and host address of the server
Copy the code

If the local public key is added to authorized_keys, the GitHub SSH_PRIVATE_KEY value is the local private key.

  1. REMOTE_HOST.required

Server address: for example, 172.0.0.1

  1. REMOTE_USER required

User name for logging in to the server

  1. REMOTE_PORT default ’22’

Port for logging in to the server. The default value is 22

  1. ARGS (optional, default ‘-rltgoDzvO‘)

I don’t understand this yet

  1. SOURCE default ”

The default directory is GITHUB_WORKSPACE. The react package file is stored in the build directory of the root directory

  1. TARGET default ‘/home/REMOTE_USER/‘

The destination file path, the address on the server to which the SOURCE file is packed, can point to the nginx configured static file address if nginx is used as the project’s static file server

Note 1: SSH_PRIVATE_KEY is an SSH private key that corresponds to the public key of SSH authorized_keys that already exists on the server.

2. Although environment variables can be defined in the ENV field in steps, the server’s privacy information is involved in sSH-deploy, and is configured using secrets

Configuration file:

		
name: newBlog deploy shell

on:
  push:
    branches: 
      - new

jobs:
  setup-build-publish-deploy:
    name: Setup, Build, Publish, and Deploy
    runs-on: ubuntu-latest
    steps:

    - name: Checkout
      uses: actions/checkout@v2
      with:
        persist-credentials: false

    - name: Install and build 🔧
      run: | yarn yarn build
 # The difference starts here
    
    - name: Deploy to Server 🚀
      # ssh-deploy action
      uses: Easingthemes/[email protected]
      env: 
        SSH_PRIVATE_KEY: The ${{ secrets.SSH_PRIVATE_KEY }}
        SOURCE: "build/"
        REMOTE_HOST: The ${{ secrets.REMOTE_HOST }}
        REMOTE_USER: The ${{ secrets.REMOTE_USER }}
        TARGET: The ${{ secrets.REMOTE_TARGET }}
Copy the code