Prerender-spa-plugin is a prerender-spa-plugin for a minivue project. When we launched our website, we started thinking that every change had to be deployed to the server, and that it was time to automate the whole thing.
What this article will cover is
- Webhook is what? When should you use it?
- How to use Webhook to free our hands?
- summary
Webhook is what? When should you use it?
Taking our company as an example, our team internally uses Gitlab as the code repository, so the following content is practiced in Gitlab, of course, it is also similar on Github.
A Webhook is, as the name suggests, a hook. When we do something specific on Gitlab, we can trigger hooks to execute scripts that we have programmed to perform certain functions (for example, automatic front-end project publishing).
Maybe those who are familiar with Gitlab will say, isn’t it CI? Why don’t we need to engage in Webhook when CI is in good place? Indeed, CI can accomplish the same function, but also in the context of the actual business situation. This project is not the core project of the company, and CI runners need colleagues with Gitlab control authority to help configure it. In line with the principle of not harassing colleagues, I think we should make our own food and clothing. Since there is a simple and convenient Webhook, why not use it?
When should you use it? In my opinion, there should be at least the following points:
- Projects are not static
- You are in charge of the project
- You have access to the server where the project is deployed
You can find time to step in a hole
How to use Webhook to free our hands?
The above picture shows the webhook configuration page in Gitlab. When we have successfully carried out some or some internal actions, such as Push events– a successful Push of the code, no matter which branch is pushed, can Trigger hook……
Gitlab will then automatically send a POST request to the link in the URL for us, which can be a script or a service, as long as it successfully receives the request from Gitlab. In this practice, I set up a Node service to help automate deployment.
The problem is that asking for that URL triggers the deployment process in the Node service. What if someone is playing with that interface all the time? It’s possible… Therefore, Gitlab gave us the opportunity to set Secret Token. Only when we detected the request with this special Token could we consider the request as safe and acceptable.
It will be sent with the request in the X-Gitlab-Token HTTP header.
The x-Gitlab-token header will not be found. The x-Gitlab-token header will only be found
Here’s how on the server we receive the Gitlab request and perform the deployment
const exec = require('child_process').exec
const express = require('express')
const app = express()
let isLocking = false
app.post('/deploy'.function (req, res) {
let headers = req.headers
let cmdStr = 'cd ... && git fetch origin && ... '
if(! isLocking && headers['x-gitlab-token'= = ='xxx') {
isLocking = true
exec(cmdStr, function (err, stdout, stderr) {
if (err) {
// ...
console.log('error:' + stderr);
} else {
// ...
console.log(stdout)
isLocking = false}})}/ /...
})
app.listen(1234.'0.0.0.0'.function () {
console.log(`listening on port 1234`)})Copy the code
On the machine where the project is deployed, we run this simple Node service, which basically means that when Gitlab posts a request, we authenticate it, and then execute a command line statement through Node, invoking different methods depending on the result. There are a few potholes here
Node Service Construction
For convenience, we rely on express. Of course, we can use HTTP module to complete these operations. In addition, when listening to the port, we need to confirm whether the current port can be accessed by the external network.
Node executes the server command line
We can use the exec method of node’s ‘child_process’ module to execute the command line statement. We simply pass the defined command line statement string to the exec method as the first argument, followed by a callback to the execution result, which can be designed according to the business needs.
Release authentication && Release status
The tokens brought in the Gitlab request are used to determine whether the request can trigger the following deployment, and a “in release” state is required to prevent the unpredictable consequences of multiple requests.
The code above is just a basic publishing service that can do anything, publish notifications of completion or failure, even check the submitted code and reject the automatic deployment…… if it does not meet the specification Anything is possible if you want to. This reflects the flexibility of Webhook, where a simple manipulation of Git can topple dominoes and accomplish something unexpected.
summary
This is the first time benchetuzai stepped on this aspect of the pit, hoping to help the cute new students, but also hope that they pat. Next, there will be a python based automatic deployment of wechat notification script, please wait for it, of course not 🙂