A few days ago, I used the Webhook of Github warehouse to trigger the Git pull of the server when I was studying the front-end automatic deployment. It turns out that sometimes the code on the server is not updated after push code is published.

Later, after testing, it was found that it was caused by the excessively long git pull execution time in some cases. Releasing Github as a code server is a bit of a stretch here for some well-known reasons.


Therefore, I decided to use my own server to build a code publishing server, using Gogs here. I also tried Gitlab before, but had to give up due to insufficient server memory. The process of building Gogs is actually much simpler than Gitlab.


My code server address


First open the command line and type

Wget HTTP: / / https://dl.gogs.io/0.11.91/gogs_0.11.91_linux_amd64.zipCopy the code
Here I use ali cloud Centos server, the lowest configuration, usually put some of their own projects. Of course, if you are a different system, or choose not to use WGET. You can also go to the Gogs website to send the packet down to the server.


Next step: Unpack

Unzip gogs_0. 11.91 _linux_amd64. ZipCopy the code
Then. And then there was no more. At this point, the installation is complete. Easy enough!


Next step: Run

./gogs/gogs webCopy the code
At this point, access port 3000 of the server and you will see the following page.




This step is to configure the Gogs server before it can be used.

For convenience, I chose the simplest configuration:




Install and the page jumps to:




At this point. The Gogs code server installation is configured and ready to use.

Of course, this is a Linux installation. If you want to set up under Windows it’s the same thing, just don’t replace localhost with your own domain name.


Because my real server runs it. Therefore, Gogs also needs to be configured as a system service. Otherwise, the Gogs will stop when the shell is leveled.


The specific steps are as follows:

Perform:

cp ./gogs/scripts/systemd/gogs.service /etc/systemd/system/gogs.service
vi /etc/systemd/system/gogs.serviceCopy the code
Change the file to:




Here are mainly modified access users and access folders. I’m using root, root folder. Because this is more convenient, of course, you can also configure users separately if you need to.

Such a simple code server is set up. Of course, in addition to this installation method, the official also provides other installation methods:



The binary installation used here.

Once the installation is complete, the coding begins. Create a new repository and add a source to the native code:

git remote add gogs http://yinchengnuo.com:3000/yinchengnuo/mockApiNode.gitCopy the code
Run git remote -v

gogs    http://yinchengnuo.com:3000/yinchengnuo/mockApiNode.git (fetch)
gogs    http://yinchengnuo.com:3000/yinchengnuo/mockApiNode.git (push)
origin  https://github.com/yinchengnuo/mockApiNode.git (fetch)
origin  https://github.com/yinchengnuo/mockApiNode.git (push)Copy the code
Add directives to package.json:

"push": "git add . && git commit -m 'publish' && git push gogs master --force && git push origin master --force"Copy the code
Perform:

npm run pushCopy the code
There is code on the code server:


Next, add webHook:


As a final step, change the server code origin:




Of course, the interface of the address filled in in webHook is already written:

    router.post("/gitHook", async (ctx) => { // github hook
        execSync('git reset --hard && git pull origin master --force')
        ctx.body = ""
    })Copy the code
It’s that simple.


In the real world, of course. Whether dealing with code server users, or webHook, etc., the limit to limit the right, the encryption to encrypt, must not ignore security issues. Here is just as a front-end white here a little try and explore the record, I hope to be able to help you all.