preface

I used to use Travis for automatic deployment of blog. However, a series of problems occurred after Travis domain name was migrated from.org to.com. Travis login failed for some reason, and only token login could be used. Each deployment receives two email pushes, one from two domain names. Consulted a lot of information but did not solve, if the readers encounter the same problem, welcome to exchange guidance, thank you very much!

In view of this, the decision was made to switch to Github Actions for automatic deployment. There are many articles on how to migrate online, as well as migrating from Travis CI to Github Actions. This article focuses on the key steps and points to note. For details, please refer to GitHub Actions

Use dead simple Actions

The mainstream public free continuous integration services include:

  • Travis CI (Github only)
  • Jenkins
  • Circle CI
  • Azure Pipeline
  • GitHub Actions (GitHub only)

GitHub Actions is GitHub’s own continuous integration and automation workflow service. To enable the Github Actions service, create a. Github /workflows folder in the repository root directory and place your workflow configuration (YAML files) there.

Example Set up an SSH key pair

To deploy files to a remote server, you must first resolve the issue of login verification so that SSH keys can be used once and for all.

  1. Generating an SSH Key

    > ssh-keygen -t rsa -f <mysite> # mysite optional, default id_rsa
Copy the code

    SSH generates two files: mysite (private key) and mysite.pub (public key). The private key is your personal login credentials, can not be shared with others, if others get your private key, you can log in to your server. The public key must be placed on the target server.

  2. Paste the contents of the public key mysite.pub to ~/.ssh/authorized_keys of the target server

  3. [Optional] Ensure that the server ~/. SSH folder has permissions lower than 711, I will use 600 (only this user can read and write) :

    > chmod 600 -R ~/.ssh
Copy the code

  4. Finally, look at the private key file mysite and copy the contents for future use. The private key file content is roughly as follows:

      -----BEGIN RSA PRIVATE KEY-----
  ...
  -----END RSA PRIVATE KEY-----
Copy the code

Note that the default private key, the public key name is id_RSA, id_rsa_pub, if the default name of the key is configured to the server, the local machine can achieve secret free login

Configure the key to the GitHub repository

Open your website repository, click the Settings TAB, find the Secrets Settings: create secret, write just generated key, name your own, directly above:

Writing workflow files

The GitHub Actions configuration file is called the Workflow file and is stored in the. GitHub /workflows directory of the repository.

Workflow files are in YAML format. The file name can be arbitrary, but the file name extension is. Yml, for example, foo.yml. A library can have multiple Workflow files. GitHub automatically runs a. Yml file when it finds one in the. GitHub /workflows directory.

The Workflow file has many configuration fields. See the workflow syntax in GitHub Actions. Here are some basic fields.

  • Name Indicates the name of the workflow. GitHub displays the name of the workflow on the actions page of the repository. If name is omitted, GitHub sets it to the workflow file path relative to the repository root.

  • On required. The name of the GitHub event that triggers the workflow. You can provide a single event string, array of events, array of event types, or event configuration map to schedule the execution of a workflow, or to limit the execution of a workflow to specific file, tag, or branch changes. For a list of available events, see Events that Trigger workflow.

  • On. “push | pull_request >. < tags | branches > specifies the trigger event occurs, can qualified branches or tags.

    on:
  push:
    branches:    
      - master
Copy the code

  • You can use POSIX CRon syntax to schedule workflows to run at a specific UTC time. The scheduled workflow runs on the latest commit of the default or base branch. The minimum interval at which you can run scheduled workflows is every 5 minutes.

  • A map of the ENV environment variable is available for all job steps in the workflow. You can also set environment variables that apply only to steps for a single job or to a single step. Example:

      env:
    SERVER: production
Copy the code

  • Defaults is a map of default Settings applied to all jobs in the workflow. You can also set the default Settings that are only available for jobs.

    When multiple defaults are defined with the same name, GitHub uses the most specific default. For example, the default Settings defined in the job override the default Settings of the same name defined in the workflow.

  • A JOBS workflow operation consists of one or more jobs. Jobs are run in parallel by default. To run the jobs sequentially, you can define dependencies on other jobs using the

    NEEDS keyword.

    Each job runs in the runs-on specified runner environment.

    An unlimited number of jobs can be run within the usage limits of the workflow.

  • Jobs.

    Each job must be associated with an ID. The key value job_id is a string whose value is an image of the job configuration data.

    must be replaced with a string unique to the Jobs object.

    must start with a letter or underscore and contain only alphanumeric characters, hyphens (-), or underscores (_).


    jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job
Copy the code

  • A map of the env environment variable is available for all steps in a job. You can also set environment variables for an entire workflow or for a single step. When multiple environment variables are defined with the same name, GitHub uses the most specific environment variable. For example, environment variables defined in a step will override job and workflow variables with the same name when the step executes. Variables defined for the job override workflow variables with the same name when the job executes.

      jobs:
    job1:
      env:
        FIRST_NAME: Mona
Copy the code

  • Jobs.

    . Name Description of a job.

      jobs:
    my_first_job:
      name: My first job
    my_second_job:
      name: My second job
Copy the code

  • Jobs.

    . The runs-on runs-on field specifies the VM environment required for running. Mandatory. The type of machine on which the job is to run. The machine can be a GitHub hosted or self-hosted runner.

    The types of GitHub hosted runners available include:

    A virtual environment YAML workflow tag
    Windows Server 2019 Windows – the latest or Windows – 2019
    Uuntu 20.04 Ubuntu – latest or ubuntu 20.04
    Ubuntu 18.04 Ubuntu 18.04
    Ubuntu 16.04 Ubuntu 16.04
    MacOS 11.0 Big Sur Macos 11.0
    MacOS Catalina 10.15 Macos – latest or macos 10.15

    Note: The MacOS 11.0 virtual environment is currently only available as a private preview. Any user or organization that already uses this runner can continue to use it. But we are not accepting any other users or organizations at this time. Macos – Latest YAML Workflow TAB still uses the MacOS 10.15 virtual environment.

    Example:

      runs-on: ubuntu-latest
Copy the code

  • Jobs.

    . Steps The steps field specifies the running steps of each Job. It can contain one or more steps. Each step can specify the following three fields.

    • jobs.<job_id>.steps.name: Step name.
    • jobs.<job_id>.steps.run: Command or action that the step runs.
    • jobs.<job_id>.steps.env: Environment variables required for this step.

  • Jobs.

    . Needs Identifies any jobs that must be completed successfully before this job can run. It can be a string or an array of strings. If a job fails, all jobs that need it are skipped, unless they use conditional expressions that let the job continue. Examples of jobs requiring success:

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

    Examples of successful jobs are not required

    jobs:
  job1:
  job2:
    needs: job1
  job3:
    if: always()
    needs: [job1, job2]
Copy the code

    In this example, Job3 uses the always() conditional expression, so it always runs after job1 and joB2 finish, whether they succeed or not. See “Context and Expression Syntax” for more information.

  • Jobs.

    .steps[*]. Run Runs the command line program using the operating system shell. If name is not provided, the step name defaults to the text specified in the run command.

    By default, the command is run using a non-login shell. You can choose a different shell, or you can customize the shell used to run the command.

    Each run keyword represents a new process and shell in the runtime environment. When you provide multiple lines of command, each line runs in the same shell. Such as:

    • Single-line command: 
        - name: Install Dependencies
  run: npm install
Copy the code
    • Multi-line command: 
        - name: Clean install dependencies and build
  run: |
    npm ci
    npm run build
Copy the code

Tips: many configuration items, details please refer to the website docs.github.com/cn/actions

case

Here’s my personal GitBook site configuration for keeping track of miscellaneous learning; Created in the warehouse the root directory. Making/workflows folder, create a YAML file, file name set, I here named deploy yml, so the full path to the file should for. Making/workflows/deploy. Yml, I wrote the meaning of the configuration in a comment file that reads as follows:

# main.yml
name: deploy to aliyun
# Trigger mode
on: 
  push: # Trigger action
    branches:
      # trigger branch
      - master 
# task
jobs:
  # First task build
  build:
    # Select a VM
    runs-on: ubuntu-latest
    Step #
    steps:
      # use node: 10
      - name: use Node.js 10
        uses: actions/setup-node@v1
        with:
          node-version: 10
      # npm install
      - name: npm install and build
        run: |
          npm install -g gitbook-cli
          gitbook install
          gitbook build
        env:
          CI: true
      # Deploy
      - name: Deploy
        uses: easingthemes/[email protected]
        env:
          SSH_PRIVATE_KEY: ${{ secrets.AL_ACCESS_TOKEN }}
          ARGS: "-avz --delete"
          SOURCE: "_book"
          REMOTE_HOST: # your host
          REMOTE_USER: # your username
          TARGET: # your project dir
      # Back and rename
      - name: Restart server Step 3: Restart the service
        uses: appleboy/ssh-action@master
        with:
          host: "118.190.52.53" The following three configurations are similar to the previous step
          username: "root"
          key: ${{ secrets.AL_ACCESS_TOKEN }}
          If you use the database migrate script, you will migrate to the database and restart the server. If you use the database migrate script, you will migrate to the database and restart the server
          script: |
            cd /opt/html/book
            mv noteBook noteBook_$(date "+%Y%m%d_%H%M%S")
            mv _book noteBook
Copy the code

At this point, when submitting code to the Master branch, actions are automatically triggered to perform the above configuration:

Open the Github project file => Actions to view the logs

At this point, the project is automatically deployed.

The best feature of GitHub Actions is that there are many third-party images that encapsulate common steps. You just need to fill in the configuration. These images are easy to provide and publish in your GitHub repository, so they scale well. For Actions, see Github Action development to Publication [juejin.cn/post/687037…]

Reference: docs.github.com/cn/actions