Yet another topic IMHO explained in the most possible complicated way in Gitlab documentation, Gitlab pages are in fact extremely powerful and simple to use. In order to create a website with an URL of the form https://<username>.gitlab.io/<project>, there are a couple of steps to follow. First, write a Job to publish your pages, this job can be part of your project’s .gitlab-ci.yml but for some reason, official documentation gives the idea you are supposed to create a specific repository for that.
I switched to Gitlab when Github was bought by Microsoft. Call me extremist, stupid, and all the names you like, I personally felt the need to do it. And quite honestly, I’m pretty happy with that choice, Gitlab is an incredibly useful suite, we use the community version at work and would never go back. But there’s one thing that’s pretty annoying with Gitlab, their documentation organization. Honestly it’s like they don’t want you to figure out how to do things.
The reference documentation when it comes to couple golang and continuous integration in Gitlab is this one, it’s well put, easy to read and pretty accurate. Except for the caching part, or at least nowadays with go modules. This is what happens when a commit is pushed with the .gitlab-ci.yml given as an example in that document: 131 Creating cache default... 132 WARNING: /apt-cache: no matching files 133 WARNING: /go/src/github.com: no matching files 134 WARNING: /go/src/gitlab.
With all the noise around those topics I would have imagined this one had been covered thousands of time, yet I did not find a single complete resource on this subject which I found to be a basic building block: pushing docker images from GitLab CI to the Docker Hub registry. There’s actually an opened issue on Docker GitHub’s that’s sitting there for 3 years, and it really feels more like a political / strategic / commercial issue than a technical one.