This question has been asked a lot here and elsewhere. I’ve read through all the threads. I’ve tried a dozen different solutions, hacks and restarted with a new server 3 times. I’ve come to the conclusion that this is one of two things A) run with tags or B) run without tags. I was unable to find any documentation that explains what tags are or how to use them effectively. They seem to not be required anyway so I didn’t worry too much about that. Moving on to B, I set out to configure my runner to run without tags. As it turned out that’s actually default setting.
my .gitlab-cli.yml file
stages:
- test
testWeb:
stage: test
script:
- cd web
- vue-cli-service test:unit
Note: not tags: listed.
I’ve installed the runner on an Ubuntu 18.04 VPS on DO following the instructions found in the official docs here.
I didn’t run into any issues and the runner appeared under “Runners activated for this project” automatically. I thought, “Bingo! It connected.” But Pipelines didn’t run. See error above.
When things don’t work and RTFM fails, check the logs. Right? Okay. I’m not positive of where the log file is for the runner. I checked /var/log, for anything more relevant to gitlab-runner or gitlab but found nothing I wouldn’t otherwise expect to see on a stock 18.04. The only reference in the docs that I could find says they’re in the general /var/log/syslog. The generic syslog did, however, contain a reference. Okay…
I searched online for anything related to the two errors I found in the logs. From what I was reading, I believed that these errors were related to metrics and should not prevent the pipeline from running. I also found some posts relating this error to the same “tags” issue above with the same two solutions, “use tags” or “don’t use tags”. In an attempt to simplify testing I stuck with the “don’t use tags” approach. Perhaps this was in error, but not being able to dig into what tags do or how they work was proving to be more frustrating than trying to figure out why no tags wasn’t working. A less complex use case should be, theoretically, easier to debug.
The repository I’m using is simply a testing project spun up specifically for the purpose of experimenting, learning and evaluating how pipelines might be able to help our company. It contains nothing more than a default Vue JS project with default tests and it works out of the box.
My two questions are, am I even remotely close to getting this to work? What am I missing here? Is there anywhere that I can get more clarity on what’s wrong other than, “This job is stuck because the project doesn’t have any runners online assigned to it.”
Update:
While I was working on the above write up, retracing my steps to confirm I had followed the instructions correctly and collecting the screenshots - I discovered this (see image below). Completely by chance, I hovered over what appears to be a disabled warning icon. a) it’s grey. b) it doesn’t do anything if you click on it. It seems to suggest that should there be a warning, the icon would become enabled, change colors, and then allow for a click action. If it wasn’t disabled or if it were otherwise important it would have a primary color attached to it. Red, being consistent with the rest of the design language on your site. For example, see the red “pause” and “Remove Runner” buttons to the immediate right.
This happy accident uncovered a new clue, “New runner. Has not connected yet”. Searching this error led me to several recommendations including
“…delete the config.toml in my home directory” - source
Which appears to be a an issue mostly related to Windows, but I checked my home directory on my Linux machine anyway. Not there.
I looked into this issue,
sudo chown -R gitlab-runner:gitlab-runner /home/gitlab-runner - source
Which suggests the existence of and therefore need to create a gitlab-runner user. I can see how that would be an excellent approach for a final setup, but A) the documentation makes no reference to creating such a user or applying said permissions and B) I’m just experimenting and plan on tearing down this droplet shortly. Anyway, there is no home folder for said user ergo, not config file in said folder. The logs don’t seem to suggest any issue loading the config file (Which it would if it had, right?). Also, the runner was registered and is clearly reporting in the web interface, as you can see. I think it’s fair to assume that the runner on my server used the api key I gave it during the one-line install step or how else would it show up in the interface? So, if it can connect to register correctly why can’t it also connect-connect correctly without logging an error either time? The error and this solution seems counterindicative to available information, specifically the fact that it did connect. On top of that, the official documentation makes no reference to this user or directory or file.
The documentation I’m referring to is linked to in step 1 on the page where you set this all up. That page has a link that goes to the documentation on manually installing a runner on Linux.
I also found this solution,
“Simple answer: RESTART the server!” - source
Which, tbh, seems like an unusual and unnecessary step for a Linux environment. I tried it anyway. Checking the status of the runner on reboot to find it was running. Alas, it also had no effect on removing the error in the title of this post.
I found this video where I learned the command gitlab-runner --debug run - source
Fascinating tool for debugging, alas I found nothing to indicate an error on first run.
However, new tool for debugging! Let’s play! Let’s run the pipeline!! Let’s see what happens!
Here’s where things get bizarre. It worked.
The pipeline worked. It worked in the sense that it failed exactly where I would expect it to.
I don’t even know what to do with this or where to take this next? I’ve already been at this for 2.5 days. I would like to automate our testing, build and deploy cycles, but if this is the solution I’ll stick with the problem.
This started as a technical support question, but I don’t even know what question to ask right now. It’s Friday. I’m tired. I’m frustrated. I’ve got zer0 gas left for what is essentially a product trial.
