background
Simple, fast, safe and convenient is always the first choice for indie developers. Since our team’s projects are stored and managed on Github, we chose to implement CI/CD with Github Actions lightweight automated deployment, compared to Jenkins, Travis, CI and CircleCI third-party platforms.
GitHub Actions
Github Actions Official portal
GitHub provides pre-configured workflow templates that you can customize to create your own continuous integration workflow. GitHub parses the code and displays CI templates that might be appropriate for your repository. You can also select the Actions CI you want from the Marketplace query;
Example: Query file copy actions related to SCP as follows:
Marketplace official portal
Workflow Basic Concepts
workflow
Workflow, the continuous integration of a running process, is called a workflow
name
> The name of the workflow (null). If set, the workflow name will be displayed on GitHub's actions pageCopy the codeon
The name of the event that triggers the workflow. For example, push/pull_request is triggered. You can listen for only one event string, or multiple events. Events that can trigger a workflow
Example: Listen for any push and pull_request on with a list of events: [push, pull_REQUEST] "" In the above examples, any branch of the warehouse will trigger an actions process for pushing or pull_request. In practice, many branches will be created, and to better manage the process, Test /dev/uat/release, a series of branch names and release actions corresponding to the specified environment. In this case, not only need to listen for operations, but also listen for the corresponding branch name, to achieve a customized deployment configuration; Example: Listen for the push event on the main branch using multiple events with activity type or configurationCopy the codeon: push: branches: – main “`
job
Task is the main body of workflow. A workflow consists of one job or multiple jobs, representing a continuous integration operation
job_id
Each task must have an ID, which is essentially a string
runs-on
The virtual environment in which the task will run must be specified otherwise it will not work
Windows Server 2019 Windows-latest or Windows-2019 Ubuntu 20.04 ubuntu-20.04 Ubuntu 18.04 Ubuntu -latest or Windows Server 2019 Windows-latest or Windows-2019 Ubuntu 20.04 Ubuntu-20.04 Ubuntu 18.04 Ubuntu -latest Ubuntu-18.04 Ubuntu-16.04 macOS Catalina 10.15 MACOS-latest or macOS-10.15 # Run -on: Ubuntu-latest 'Copy the codesteps
Step, each task is composed of multiple steps, through one or more steps to complete a task. You can publish operations in run commands, run tasks, run operations in the repository, and the Docker registry.
Note: Not all steps run actions, but all actions run as steps, and each step has a separate process in the virtual environment that can access the workspace and file system.
name
Step name
run
The command or action that the step runs
env
Environment variables required for this step
uses
Select the actions that are part of the task step to run. The actions used by the step can be one or more actions
The project of actual combat
Let’s take the actual combat project case as an example:
-
If the.github/workflows directory does not exist, create it in the Github repository.
-
In the.github/ Workflow directory, create a file called build.yml. See “Creating a New File” for more information.
- Copy the following YAML content to
build.ymlIn the file:
name: build
on:
push:
branches:
- main
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout 🛎 ️
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:
persist-credentials: false
- name: Install and Build 🔧 # This example project is built using npm and outputs the result to the 'build' folder. Replace with the commands required to build your project, or remove this step entirely if your site is pre-built.
run: # # | lerna bootstrap installation depend on lerna run build package - name: Deploy 🚀
uses: cross-the-world/ssh-scp-ssh-pipelines@latest Since the code needs to be uploaded to the server after the build, you need to connect to SSH and do a security copy operation
env:
WELCOME: "ssh scp ssh pipelines"
LASTSSH: "Doing something after copying"
with:
host: The ${{ secrets.DR_HOST }}
user: The ${{ secrets.DR_USER }}
pass: The ${{ secrets.DR_PASS }}
port: The ${{ secrets.DR_PORT }}
connect_timeout: 10s
first_ssh: | rm -rf /usr/local/webserver/nginx/html/dist mkdir -p /usr/local/webserver/nginx/html/dist scp: | './packages/demoPro/dist/*' => /usr/local/webserver/nginx/html/dist
Copy the codeSince our project uses Monorepo’s lerna-based multi-package management project:
Pay special attention to
The DIST file for SCP security copy is the path relative to the project root directory. ‘./packages/demoPro/dist/*’
Install the and Build 🔧
To install dependencies and package this use, run the following command:
Lerna bootstrap # install lerna run build # install lerna run buildCopy the codeThe Deploy 🚀
To deploy the packaged Dist file to the specified remote server path, we need SSH connection to the server and secure copy the packaged file to the server path via SCP:
We currently use the following actions, or you can choose your own action from the Marketplace:
Action official portal
cross-the-world/ssh-scp-ssh-pipelines@latest
Copy the codeVariable definition and naming
To protect privacy, you need to use GitHub Secrets to access the build.yml file content in a variable way. As follows:
Done
The above completed a relatively simple GIthub Actions based CI/CD; We can test whether the packaged files are deployed to the specified directory on the server by triggering the push event on the main branch.
Log in to the server and run the view command
cd /usr/local/webserver/nginx/html/
Copy the code