Writing in the front

Gh-pages automated deployment, previously using the free Travis-ci.org, simple and easy to use; It was later found to have closed down the service and is recommended to migrate to travis-ci.com.

Travis-ci.com offers 10,000 free credits. These credits do not automatically increase, and each build costs a minimum of 10 credits, with fewer being used each time. And you need to bind the payment method.

So consider using Github’s official continuous integration service, Github Actions.

start

If the.github/workflows directory does not exist in your project, create it in your Github project. Create a.github folder in the project root directory and a workflows folder in the.github folder.

The GitHub Actions configuration file is called the Workflow file (we call it workflow) and is stored in the.github/workflows directory of the repository. The Workflow file is in YAML format. The file name can be arbitrary, but the file name extension is. Yml, for example, ci.yml.

Github Actions detects workflow files in your.github/workflows project and is automatically activated when triggered by events in your repository, manually triggered, or on a defined schedule. So you don’t have to worry about how to name your YML file or how to enable it.

The Workflow file has many configuration fields. For details, see the official document.

Here is an example of a complete Workflow file:

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the workflow will run
on:
  # Triggers the workflow on push events but only for the master branch
  push:
    branches: [ master ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - name: Checkout master
        uses: actions/checkout@v2 # If you're using actions/checkout@v2 you must set persist-credentials to false in most cases for the deployment to work  correctly.
        with:
          ref: master
          persist-credentials: false

      - name: Setup node
        uses: actions/setup-node@v1
        with:
          node-version: '10.x'

      - name: Install and Build
        run: yarn && yarn build

      - name: Deploy
        uses: JamesIves/[email protected]
        with:
          token: The ${{ secrets.ACCESS_TOKEN }}
          single-commit: true
          branch: gh-pages
          clean: true
          folder: docs/.vuepress/dist
Copy the code

The above configuration file is simple and serves to deploy the built pages to GH-Pages. A brief explanation of this configuration file:

  • 1. This workflow is called:CI; (Name is optional)
  • 2. Trigger conditions/events for this workflow: onlymasterbranchpushWhen an event;
  • 3,workflowThe body of the file isjobsField representing one or more tasks to be performed; This workflow contains a file namedbuildthejob;
  • 4,stepsField specifies eachjobCan contain one or more steps.
  • 5. This is calledbuildthejobConsists of four running steps; They are :(1) check out the code; (2) Set the Node environment; (3) Install dependencies and Build; (4) to deploygh-pages;

Except for step three, we are running yarn build directly. For the other three steps, we used third party actions (Actions /checkout@v2, Actions /setup-node@v1, JamesIves/[email protected]). So what is action? How to use it correctly?

Action

Actions are an important part of Github Actions. Actions such as grabbing code, running tests, logging in to a remote server, publishing to a third party server, etc., are Actions. They are already written step scripts. Just like open source code, you can use it directly.

There is an official action repository, Github Actions marketplace, and individual developed Actions. In addition, Awesome Actions has a great collection of Actions.

This means that some functions are implemented by others or provided by the authorities, so you don’t need to write your own, just import the action and use it according to the specification.

Each action is also a code repository, similar to open source management, so there is also the concept of versioning. Refer to the action using the userName/repoName syntax. For example, actions/setup-node means github.com/actions/setup-node.

Steps: - uses: actions/setup-node@74bc508 # specify a commit - uses: actions/[email protected] # specify a tag - uses: actions: Actions /setup-node@master # Specify a branchCopy the code

How do you develop an action? Sorry is beyond the scope of this article; I will introduce it in detail if I have the opportunity later.

Environment variable/encryption password

As you can see from the workflow configuration file above, we use the ${{secrets.access_token}} operation. This is an encrypted password ACCESS_TOKEN that I defined in the project repository for deployment authorization. In addition to encrypted passwords, there is also the concept of environment variables.

The following describes environment variables and encryption passwords respectively.

Environment variables can provide more dynamic functionality to our workflow, as well as control execution logic. For example, we can control the workflow to perform different operations according to different variable values; We want to implement automatic email function, must provide the email name, right, so:

GitHub sets the default environment variables for each GitHub Actions workflow run. You can also set custom environment variables in the workflow file.

Default environment variables

GitHub sets some default environment variables for each GitHub Actions workflow run. As shown below:

For more default environment variables, see the official Github Actions documentation

Customize environment variables

In addition to the official default environment variables, we can also customize environment variables. You can customize environment variables in several places: you can use env at the top of a workflow file, you can customize environment variables in a job by using Jobs.

. Env, or you can customize environment variables in a particular step by using Jobs.

.steps[*].env. As shown below:

The differences between environment variables defined in these three ways are similar to the differences between scopes when we write code, as you know.

Tip: If you want to see what environment variables are in the current workflow, in what format. You can use run:env in one of the steps and see the output of that step.

Using environment variables

When using environment variables, use the correct variable value posture; The difference is whether the content is handled by Github Actions in the workflow and not posted to the runner, or whether variables are used on the runner. As follows:

Variables that need to be handled by Github Actions in the workflow need to be evaluated using the context env or Github.

For variables that need to be sent to the runtime, you must use the runtime’s correct value syntax; In the example above, the workflow specifies the use of Ubuntu-Latest. By default, Linux runners use bash shells, so you must use the $DAY_OF_WEEK syntax. If the workflow specifies a Windows runner, you will use PowerShell syntax, $env:DAY_OF_WEEK.

How to use environment variables – Refer to documentation

Other types of variables

In most places in the workflow, the only variable types you can use are environment variables, such as $MY_VARIABLE, or corresponding context properties, such as ${env.MY_VARIABLE}}.

Alternatively, you can use input/output to pass values between jobs in a workflow. Please refer to the documentation for details.

Encrypted password

Sensitive values should never be stored in clear text in a workflow file, but should be stored as passwords. Passwords are encrypted environment variables created in an organization, warehouse, or warehouse environment.

Encrypted passwords allow you to store sensitive information in your organization, warehouse, or warehouse environment. Such as token, password, email name, email password, and sensitive information.

Creating an encrypted password

  1. On GitHub.com, go to the warehouse’s main page.
  2. Under the warehouse name, click Settings.
  3. In the left sidebar, click Secrets (Passwords).
  4. Click New Repository Secret.
  5. Type the Name of your password in the Name input box.
  6. Enter the value of the password.
  7. Click Add Secret.

Use an encrypted password

The posture of using environment variables was described earlier, and using encrypted passwords is similar.

When you want to use passwords as input or environment variables for operations, you can use the secrets context to access passwords you create in the repository.

steps:
  - name: Hello world action
    with: # Set the secret as an input
      super_secret: ${{ secrets.SuperSecret }}
    env: # Or as an environment variable
      super_secret: ${{ secrets.SuperSecret }}
Copy the code

Similar to the use of environment variables, if passwords must be passed on the command line, include them in the appropriate reference rules. Passwords often contain special characters that can accidentally affect the shell. To escape these special characters, refer to environment variables. Such as:

Steps: -shell: bash env: SUPER_SECRET: ${{secrets.supersecret}} run: | example - the command $SUPER_SECRET # in PowerShell the use of password steps: - shell: PWSH env: SUPER_SECRET: ${{ secrets.SuperSecret }} run: | example-command "$env:SUPER_SECRET"Copy the code

More on GitHub Actions encryption password usage documentation

Learned to open

Start creating your own workflow file

Reference documentation

Github Actions quick start

Github Actions YamL file configuration items

10 GitHub Actions Advancements You should Know

Write in the last

My home page: neveryu. Making. IO/index. HTML

Exchange learning group: 685486827

Wish brothers a happy year of the Tiger and a speedy divorce