Auto deploy MRs for review

(Optionally) automatically deploys the result of the CI build to a live website.

I would've loved to get this working with GitLab pages, as it would require no further configuration on the devs part, but that was not possible (as discussed in #16 (closed) and also gitlab-org/gitlab-pages#33). As a result, this uses a 3rd party service surge.sh to deploy feature branches. master is still deployed to GitLab pages as it was before.

Things to note:

• This is optional, if you don't configure your GitLab fork of this project with surge.sh credentials, the CI will run essentially the same as before.
• There are instructions in CONTRIBUTING.md about how to set this up if you want it.

Happy to answer as many questions as you may have.

The MR process in detail

Below are screenshots/links to help explain how the process is expected to work.

Deploying feature branches to surge.sh

As soon as you push a feature branch to GitLab, it will begin building the Jekyll site as it did before. This uses the build job (in the test stage):

Pipeline displayed in pipeline list

Pipeline displayed in more detail

Viewing the "Environment" which CI created

The .gitlab-ci.yaml is now configured to create a GitLab "Environment" for each build. Here is the environment for this MR, and here is the pipeline which build it. Things to note about these environments:

• There is one for each branch that you push.
• It will get created if you have followed the instructions in CONTRIBUTING.md to setup surge.sh.
• It is aware of the URL it was deployed to (e.g. https://auto-deploy-mrs-fdroid-website-pserwylo.surge.sh/ for this MR).
• That URL is displayed in various places throughout GitLab (most notably embedded in the MR).
• The environment is automatically removed once the source branch is removed (e.g. automatically if you have enabled "Remove source branch when merge request is accepted" when proposing MRs).
• The link is public to anybody.
• The GitLab UI may elect not to display the link to you unless you are logged in. I haven't quite figured out exactly when it decides to hide it.

In case it is not visible for this MR, here is what it is expected to look like:

And viewing the link takes you to here:

Tearing down deployment after merge

Once the source branch is removed, or you manually click the "Stop environment" button from within GitLab, the surge.sh site will be removed. Here is a pipeline which shows that happening for a test MR before this one, resulting in this command:

Deploying master to GitLab pages

If a MR is accepted and thus merged into master, a separate build process will happen, almost exactly like what happened before. Two things will happen in response:

The staging environment will be removed (pipeline)

(if you have "Remove source branch when merge request is accepted" enabled)

The master build will deploy to GitLab pages (pipeline)