This article explains how to ci/cd our project through github actions.
("Original address: /ancold/p/18327097").
I. Introduction to actions
GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform for automating your build, test, and deployment pipelines. You can create workflows to build and test each pull request for a repository, or deploy a merged pull request to a production environment.
GitHub Actions goes beyond DevOps and allows you to run workflows when other events occur in your repository. For example, you can run a workflow to automatically add the appropriate tags when someone creates a new issue in your repository.
GitHub offers Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure.
Here is a simple example and synopsis
# Optional - The name of the workflow, which will be displayed in the "Actions" tab of your GitHub repository. If this field is omitted, the name of the workflow file will be used.
name: learn-github-actions
# Optional - The name of the workflow run generated from the workflow, which will be displayed in the list of workflow runs in the "Actions" tab of your repository. This example uses an expression with a `github` context to display the username of the user who triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)".
run-name: ${{ }} is learning GitHub Actions
# Specify the trigger that triggers this workflow. This example uses the `push` event, so the workflow is triggered to run every time someone pushes a change to the repository or merges a pull request. This is triggered by pushing to each branch; for an example syntax that only runs when pushing to a specific branch, path, or tag, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_ requestpull_request_targetpathspaths-ignore)".
on: [push]
# Group all tasks running in the `learn-github-actions` workflow together.
jobs.
# Define a task named `check-bats-version`. The subkey will define the properties of this task.
check-bats-version.
# Configure the task to run on the latest version of the Ubuntu Linux runner. This means that the task will run on a new virtual machine hosted by GitHub. For an example of the syntax for using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
runs-on: ubuntu-latest
# Group together all the steps run in the `check-bats-version` task. Each item nested under this section is a separate action or shell script.
steps.
# `uses` The `uses` keyword specifies that this step will run the `v4` version of the `actions/checkout` operation. This is an action that checks out your repository to the runner, allowing you to run scripts or other actions (such as build and test tools) against your code. You should use the checkout action when your workflow will use code from the repository.
- uses: actions/checkout@v4
# This step uses the `actions/setup-node@v4` action to install the specified version . (This example uses version 20.) This puts the `node` and `npm` commands into your `PATH`.
- uses: actions/setup-node@v4
with.
node-version: '20'
The # `run` keyword tells the task to execute the command on the runner. In this case, you are using `npm` to install the `bats` software test package.
- run: npm install -g bats
# Finally, you will run the `bats` command with the output software version parameter.
- run: bats -v
II. Front-loading actions
- Prepare a server
- Apply for AliCloud Mirror Warehouse Service, application address:/
- Normal access to github
- Create a new Java SpringBoot project to push to github code repository
- Configure the corresponding secrets and variables in the code repository, which will be taught in the next step.
III. Configuring secrets and variables
The specific configuration location is shown below
The example I'm using here uses some of the following secrets
- DOCKER_LOGIN_URL AliCloud mirror repository address
- DOCKER_PASSWORD AliCloud Mirror Repository Password
- DOCKER_USERNAME AliCloud Mirror Repository Account Number
- SERVER_IP Server Ip
- SERVER_USER_NAME Server name
- SSH_PASSWORD Server password
IV. Creating workflows
Click Actions--New workflows and it will create a folder .github\workflows in the project directory by default.
Select the Docker image
V. Writing a Dockerfile
Because it is mainly used to do an example, so my side of the Dockerfile written on the relatively simple, if you have their own needs, labor please modify their own
The Dockerfile is stored at: .github\workflows Same level
FROM openjdk:17
WORKDIR /app
COPY spring-boot-build-3.3. /app/spring-boot-build-3.3.
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app/spring-boot-build-3.3."]
VI. Writing release pipeline configurations
name: Docker-Image-CI
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Check out the code
uses: actions/checkout@v2
- name: Set up QEMU
uses: docker/setup-qemu-action@v1
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1
- name: Set up JDK 17
uses: actions/setup-java@v3
with:
java-version: '17'
distribution: 'temurin'
- name: Build with Maven
run: mvn clean package
- name: Move JAR to .github/workflows
run: |
mkdir -p .github/workflows
mv target/*.jar .github/workflows/
- name: Log in to Aliyun Docker Registry
env:
ALIYUN_DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
ALIYUN_DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }}
ALIYUN_DOCKER_URL: ${{ secrets.DOCKER_LOGIN_URL }}
run: |
echo "${ALIYUN_DOCKER_PASSWORD}" | docker login "${ALIYUN_DOCKER_URL}" --username "${ALIYUN_DOCKER_USERNAME}" --password-stdin
- name: Remove old Docker images
run: |
docker images --format '{{.Repository}}:{{.Tag}}' | grep '/benxiong_default/public' | xargs -I {} docker rmi -f {}
- name: Build Docker image
run: docker build -f .github/workflows/Dockerfile -t springbuild .github/workflows/
- name: Tag Docker image
run: docker tag springbuild AliCloud Mirror Repositorytag:latest
- name: Push Docker image to Aliyun registry
run: docker push AliCloud Mirror Repository地址:latest
- name: Set up SSH using username and password
env:
SSH_PASSWORD: ${{ secrets.SSH_PASSWORD }}
SSH_USER: ${{ secrets.SERVER_USER_NAME }}
SERVER_IP: ${{ secrets.SERVER_IP }}
run: |
sudo apt-get update
sudo apt-get install -y sshpass
sshpass -p "${SSH_PASSWORD}" ssh -o StrictHostKeyChecking=no ${SSH_USER}@${SERVER_IP} << 'EOF'
# Stop and remove old container
sudo docker ps -q -f "name=Container name" | xargs -r sudo docker stop
sudo docker ps -aq -f "name=Container name" | xargs -r sudo docker rm
# Remove old Docker images
sudo docker image prune -a -f
# Remove the specific Docker image
sudo docker rmi -f Mirror Name
# Pull the new Docker image
sudo docker pull Mirror Name
# Run the new container
sudo docker run -d --name Container name--restart unless-stopped -p 9000:9000 Mirror Name:latest
EOF
VII. Conclusion
Through the above set of operations down, we can submit the code after the main branch, through the workflows can automatically go to help us perform the build and deployment of the operation, very convenient for us developers, we do not need to go to the deployment of jenkins, do not need to learn jenkins pipeline syntax, and also have to say a word. github nb!
gthub actionsOfficial address:/zh/actions/learn-github-actions/understanding-github-actions
If there is anything that is not clear or wrong, please feel free to correct me!
If you like it why don't you give it a like and bookmark it 🙂