Oops… It was really never broken. It was just pointing to the wrong location. Big oof..
CI/CD Funtimes
Gitlab offers a really nice gitlab-ci service to automate all the things. I use it to build docker images and then push those docker images to dockerhub. For more details, I covered building a pipeline in a previous post on 2019-09-03-gitlab-ci-cd.. (PS that post is mostly a rip off of another blog post. I will in no way take credit for that work; well.. maybe a small set of the customizable changes..)
In Gitlab’s cicd, I’m pretty sure logging is open and avialble. (available or not, there’s no chance I log passwords or sensitive data) Within the variables portion of the setup, there are some important variables that need to be set and filtered out of the output to have a docker image pushed to a registry! These important variables include:
CI_REGISTRYCI_REGISTRY_IMAGECI_REGISTRY_PASSWORDCI_REGISTRY_USER
These are used mainly to point to the specific registry, to login, and to point to where the remote image where is stored. I set and forgot them like any busy person would do.
No big deal right, wrong.
I wasn’t comprehending why my docker images weren’t being pushed to the correct location. They weren’t being pushed to hub.docker.com and I wasn’t seeing them anywhere. The log output was showing the push was successful and I was seeing nothing but green ligts, but I couldn’t understand what was happening and why I wasn’t seeing the image pushed up to dockerhub! It was frustration at its finest.. I even opened a ticket with docker support I was so shook.
It was only until I noticed the image was being pushed to Gitlab’s internal registry and not to dockerhub.
Logs
As I was working on the issue today and pushing new tags to the repo thinking a tag push would solve my problems, I noticed in the cicd log output my image was being redirected and pushed to the gitlab registry… I then checked the gitlab registry and sure enough, all my created images were there. The problem that never existed had solved itself.