Home > Technical & Creative Skills > Programming, Servers & Scripts

---

Plutus Toolkit - Automatic GitHub deployment using webhooks (14)

---

CAUTION! This contribution is 100% technical.

Problem: I found myself in a situation where I wanted to deploy my landing pages after pushing changes to the main GitHub branch without connecting to the production server and without losing possibility to review changes online (GitHub). I hardly found any ready-to-solution so I prepared one.
Solution: https://gist.github.com/piotrusin/04...efe73b570c009a

What It Does?

This is simple install script that is:

1. installing curl, git and go
2. downloading source code of https://github.com/adnanh/webhook and is building it
3. creating webhooks directory in /var/www
4. moving compiled webhook binary into var/www/webhooks
5. creating hooks.json file and moving it into /var/www/webhooks - a configuration of webhook module
6. creating simple-pull.sh - a bash script that executes git pull after changes are pushed to the main branch
7. creating webhook.service and running it - this just basically launch a webhook server (more info in docs from the link posted above).

How It Works?

Webook service is starting a web server at port 9000 that is listening for the requests.

Request is fired from the GitHub using webhook after pushing anything to the repository. Payload looks like this: https://developer.github.com/webhook...payloads/#push

Each request is then processed based on hooks.json conditions and if all conditions are matched, selected bash script is executed with possible arguments from the request.

This bash script can be anything, from simple echo's to sophisticated building pipelines, in this script's case it is just simple git pull that fetches recent changes on the production server (solving "Problem" stated above)

Example Webhook URL looks like this: http://yourdomain.com:9000/hooks/deploy - deploy here is an "id" from the hooks.json, this file can be updated accordingly to the docs to execute more complicated builds if you ever wished so.

Prerequisites

Github account.

Production server with proper A record set to yourdomain.com

Github repository deployed to the production server.

Webhook set up in the repository settings:



Webhook URL is: http://yourdomain.com:9000/hooks/deploy

Where yourdomain.com must be replaced with the production domain that you are using to host your code.

Secret: this is hash that you use in both install script and GitHub webhook. Both values must be THE SAME.

This is security measure, requests without proper secret are rejected and deployment is NOT processed.

After each push to the GitHub repository a webhook that you created is executed, posting a request to the http://yourdomain.com:9000/hooks/deploy that deploys your code automatically (see "How It Works?")

Using Custom Subdomain With SSL Certificate

Here is the post about how to get it done using Apache: https://stmforum.com/forum/showthrea...l=1#post411415

Conclusion

I'm leaving that gist here because of two reasons:
1. to reference it later on after changing up my server - explanation will help me to remember what the hell is going on in this thing
2. to help anyone resolve the problem that I myself encountered

As always - hope it helps.

plutus

---

Another tool added to the magic box!
@plutus. For those of us that are somewhat technically-challenged, what are some scenarios where you would use this script?

Thank you!!


Amy


Sent from my iPhone using STM Forums

---

Main scenario in the current version is following:
1. You have your own server
2. You added DNS record that point to that server
3. You created repository with your codebase
4. You pulled that repository on your server once
5. You set up webserver to serve files from that repository when accessing your domain

Now the script kicks in.

It set up webhook module that will automatically pull any further changes from the repository when they occur.

One important note is that the GitHub repository name must match document root directory name of your website.

The way it works right now, is that it requires repository that is already deployed once and set up in the web server.

The way I want it to work in the near future is fully automation, which is possible but require a bit more server-side tweaking before it’s ready to go.


Sent from my iPhone using STM Forums mobile app

---

For those using S3 / CloudFront, this can be done using AWS CodePipeline.

https://stmforum.com/forum/showthrea...-LPs-using-AWS

---

Top notch share!
One of those things I've meant to get round to myself to make things more efficient!

---

Thanks @plutus for the explanation!

One more question from this tech-noob: What would be the advantage of using Github to serve the landers? Their CDN capability?


Amy


Sent from my iPhone using STM Forums

---

He is not using Github to serve the landers, only for version control.

---

Automation, development and deployment speed.

Static files (htmls, css, js, assets like images and icons) are served by the CDN In both cases - S3 one and self-hosted one.

Let's say that you have "landers" directory that you decide to use as a project and store on GitHub.

Think of repository as a list of revisions of that project.

In the repository you can store list of changes you made to files in your "landers" directory compared to the previous version that is stored on the GitHub.

Each time you change something (modify file(s), add file(s), remove file(s), rename file(s)) on your local machine you have a possibility to update it on the GitHub.

Updating it on GitHub is made by your decision on which of your local new/removed/changed/renamed files from the "landers" directory should be added in the next revision (add & commit)

After you decide on changes you wish to store, you can update your revision list on GitHub (push)

This is where this tool kicks in, when you update your revision list (push changes to the repository) it detects it and automatically adjust your production server (server that you use to host your "landers" directory) with the newest changes.

To put it simply - this just removes a step where you need to connect to your server to download the most recent changes.

So in our case Updating revision list = making all of the changes visible on your server instantly.

Example:
Let's say that you add a new file named "test.html" with the short text "Hello STM!" to your "landers" directory.

You now decide to add it to revision list (add & commit) and update it on the GitHub (push).

When you execute push command, your server will automatically detect it (if my script was installed and configured properly) and update files to the latest version.

In other words, you can now visit yourdomain.com/test.html to see "Hello STM!" text.

No upload or manual connection is needed.

You would still need to manually clear CDN/CloudFlare cache in case of changing file instead of adding a new one.

This is a way CDNs works, clearing CDN caches can also be automated but it is a bit harder to achieve.

Hope this makes sense.

Just to be clear: this was just super-over-simplified explanation of a git basic functionalities, this is a bit more complex topic - I'm limited by the STM gods by the sheer amount of characters I can type in here so unfortunately can't cover it as a whole for you in this post.

Would you be interested in learning git & GitHub?

This would make another nice contribution.

Understanding the git basics is not that much of a hassle to learn.

It's getting more complicated when you dive deep into it branching, but it's a part of git functionality that would never be utilized by any affiliate working alone.

---

Jeremie posted while I was typing my response, he's right.

GitHub is just a place where you store "revisions" of your project (explained in my previous post).

Hosting landers based on GitHub can be basically done in two ways:
1. Having your own server that fetches changes from your GitHub repository - this one require technical knowledge of setting up web server and also php + database in case of PHPish files.
2. Using third-party service that does that for you and is based on your GitHub repository - Jeremie already posted a link how this can be achieved with S3/Cloudfront in one of his previous posts

---

@plutus @jeremie You guys are so awesome - thanks for taking the time to explain all that for my benefit!

While updating the 40-day tutorial - the lesson on lander infrastructure - I came across the option to enable bucket file version control on S3. I'm assuming the push process can't be automated there using existing options on S3/Cloudfront? Thus the immense value of your script.

Thanks again!


Amy


Sent from my iPhone using STM Forums

---

CloudFront is CDN. S3 is static storage. These two services can not automate anything because they do not have automation built-in capabilities.

S3 version control allows to restore a previous version, but it is always at file level. When modifying code, you may modify several files at the same time (like HTML + CSS + 2 images for example). If you need to revert, you must get back to the previous versions of all these files at the same time. This is what GitHub allows.

On top of that, GitHub allows you to use repositories inside others, by embedding them as submodule. So I have my Hugo master theme for landing pages, with all my JS scripts (push subs / tracker pixel) in one GitHub repo. And then, I have one GitHub repo per vertical, which use the main GitHub repo as template, and I just have to concentrate on the landing page content, all the scripts being added automatically. So for example, if I need to modify my Voluum pixel if my tracking domain gets banned, I have just one update to do, then a few Hugo commands to rebuild all landing pages. And then they get pushed to S3 (and CF CDN)... Takes 5 minutes... + refreshing CloudFront, which is more complicated to automate, see here.

---

Great thread, I absolutely enjoy to read about all these technical things that can be implemented in affiliate marketing

---

I managed to configure this using SSL and subdomain, for anyone interested here is the step by step guide

Things that are needed here are:
1. gist from the first post installed
2. certbot cli (script that is used to generate FREE SSL certificates using Let's Encrypt)
3. proper DNS setup, using CNAME record, webhooks -> @
4. Apache2 webserver (100% sure this will also work with ngnix)

So, you start out by setting up CNAME record in your domain registrar.

Use CNAME record as host use webhooks and point it to @ (so you end up with webhooks.yourdomain.com)

Now, wait till DNS propagates (usually it takes less than 5 minutes but can be up to 24 hours).

Next, generate certificate for your newly created subdomain using certbot:

Now, set up your vhost:

and paste the following (replace yourdomain.com with your domain):

Enable vhost:
And restart server:
From now on, you can set up your webhooks in GitHub using webhooks.yourdomain.com/hooks/deploy

---

Too valuable a solution to be buried on post 13 in the thread! Perhaps link to it from the original post?

Thanks so much!



Amy

---

Home > Technical & Creative Skills > Programming, Servers & Scripts