When I visited Github, the home page always recommended some projects that use script check-in. When I was bored, I clicked open and looked through the source code. After confirming that there was no risk and ref code, I tried automatic check-in and it was quite good.

In a post on V2ex about Github Actions, someone replied that you can use Github + Drone to perform tasks

The so-called CI/CD

As a non-professional, I have used Google but still don’t know what it is, of course:

  • Continuous Integration. Well, it’s sort of a software engineering process…
  • Continuous D–
    • Delivery continues. A software engineering maneuver?
    • Deployment continuous Deployment. Deploy software to production in an automated manner.

OK, surrender! I combined a bunch of words I understood into some unintelligible terminology 🙄

The traditional mainstream CI/CD platform, which most companies use to this day, is open source Jenkins. Instead of publishing manually, it can:

  1. Automated build
  2. The deployment of
  3. User permissions
  4. etc… Some extra scripting capabilities

A digression

At that time, the construction process of the front-end release of the company disappeared after the implementation, but the leader at a higher level saw that a platform had the function of version rollback, so he required the front-end release to think of a degradation plan, grasp the rollback, and form a closed loop with the version, enabling the business… It’s a myth, but it smells like a one-two punch.

The general scenario is the front-end release to achieve a version rollback function, I have no experience in the face of meng, this is not the operation and maintenance do?

Anyway, not knowing what their back end was doing, the front end leader and OPS came up with a solution: save the build artifacts from the last release.

My suggestion at the time was to simply go back to the COMMIT from that release and build again. Jenkins can tag the warehouse automatically when you post. Every time you post and forget to tag the warehouse, there will always be a few happy people.

However, it does not help. The front-end leader takes into account the reasons of relying on the version, and the higher level leader is afraid of building inconsistent products again…

Just thought Jenkins might have a plugin like this, looked around for a while, wrote down the alternative: keep the historical build again, but store it in a specific location, and compress it into a.tar package named with the date and version number.

Container native Drone

With the popularity of containerized Docker, deployment is also much faster. Most of the deployment can be completed with only a Dockerfile, saving the need to build a variety of dependent environments.

Drone is a container-native, Continuous Delivery Platform. Project address: github.com/drone/drone

Cloud.drone. IO is already available, but you can log in and use it locally.

Reveal the plot in advance, local installation down no problem, use up the brain kuo son pain 😂

The preparatory work

First, open the official documentation and find that you need to install two things: Server and Runner.

Create OAuth application with ciphertext

Drone deeply integrates with multiple SCM sites, and you can see a list of Providers it supports in the documentation. Take Github, the most commonly used provider, as an example.

Go to Settings -> Developer Settings -> OAuth Apps, create and fill in the website address and authorization callback URL. Focus on saving its Client ID and Client secrets to configure the environment variables required when drone runs.

Then create a ciphertext for the communication between the server and runner:

$ openssl rand -hex 16
bea26a2221fd8090ea38720fc445eca6
Copy the code

Install and configure the server

$ docker pull drone/drone:1
$ docker volume create drone-data # Data storage
$Docker run \ -d \ -v drone-data:/data \ -e DRONE_GITHUB_CLIENT_ID={{previously obtained Client ID}} \ -e DRONE_GITHUB_CLIENT_SECRET={{previously obtained Client secrets}} \ -e DRONE_RPC_SECRET={{previously obtained ciphertext}} \ -e DRONE_SERVER_HOST=localhost:9005 \ -e DRONE_SERVER_PROTO=http \ -p 9005:80 \ -p 443:443 \# omit without HTTPS
    --name=drone \
    drone/drone:1
Copy the code

< span style = “box-sizing: border-box! Important; word-break: inherit! Important;

Install and configure Runner

You can choose docker environment, local machine environment, etc. Docker, of course.

Note Only the 1809 and 1903 versions are supported on a Windows PC. Here is an example in Linux:

$ docker pull drone/drone-runner-docker:1
$ docker run \
    -d \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -e DRONE_RPC_PROTO=http \
    -e DRONE_RPC_HOST=drone \ Use the same server container name as before-e DRONE_RPC_SECRET={{previously obtained ciphertext}} \ -e DRONE_RUNNER_CAPACITY=2 \ -e DRONE_RUNNER_NAME=${HOSTNAME} \ -p 300:3000 \ --name drone-runner \ drone/drone-runner-docker:1Copy the code

If the Windows version does not support it, you can install Exec Runner. Download a drone-runner-exec file, rename it to.exe, write the configuration and install it as a service.

Create a network between network-connected containers:

$ docker network create drone
$ docker network connect drone drone
$ docker network connect drone drone-runner
$ Verify that the command succeeded
$ docker logs drone-runner

INFO[0000] starting the server
INFO[0000] successfully pinged the remote server
Copy the code

Build plan file

Similar to the Github Actions workflow, you create a.drone.yml file in the project root directory, fill in the dependency environment and commands, and then each commit/ PR triggers the build task.

A Node-based example:

kind: pipeline
name: default

steps:
- name: test
  image: node
  commands:
  - yarn
  - yarn test
Copy the code

The resulting experience and the problems encountered

The result after a long time:

Project activation failed

There was a problem enabling your repository. Validation Failed.

The problem is that Drone failed to create webhooks, Github does not allow the creation of local webhooks of type localhost because they are executed locally and cannot be located to specific user hosts. You can use tools like ngrok to bind local services to the public network.

The quickest solution is to deploy a VPS.

The user management interface is missing

A visit to drone, directly jumped to the third party login authorization interface, there is no registration/login process…

Docker environment variable:

DRONE_USER_CREATE=username:octocat,admin:true
Copy the code

Create and manage users through the command line… Don’t give up I went to turn over drone-UI interface source code, written with VUE, there are a few months did not update, issues and in the fight…

As expected, there is no page related to user management in the routers. There is a login form, but there is no registration at all. What about the default registration? Neither does plugin ecology, pawn 😦

In general, as a CI/CD platform, its core functions are available, but its ecology needs to be improved.

Refer to the link

  • CI/CD wiki
  • Drone Docs

The original link station drainage (blog) : www.ningtaostudy.cn/articles/bp…