I recently upgraded gitlab-ce from v13.6.2 to v13.7.1 on my Gentoo installation. Quite a lot changed, but I got it working again. One thing is still missing. A new commit does ot trigger a new pipeline though .gitlab-ci.yml is in place and OK and there is a shared runner (v13.3) available. Tiggering a new pipeline via UI works just fine.
Since Sidekiq is now started via sidekiq-cluster, I assume a job/queue is missing there, but I’m not sure how to troubleshoot or look for more information.
Hey, sorry for the late response. I’m not too sure what exactly I should post. I made some screenshots showing the runner in the admin panel [1], the CI/CD settings of the project itself [2], and the corresponding .gitlab-ci.yml [3] (in case someone wonders: I did not commit with “WIP” in the commit message). I found some jobs in the sidekiq config having pipeline in the name, so I suppose, at least sme of them might be related. Prior to the update I had a specific runner (same version) on the project that worked, but changing the runner to be specific does not change the behavior right now; so I suspect some kind of misconfiguration, but I don’t know what to look for. The main change for sidekiq was, that it is now started via sidekiq-cluser from the distribution having that weird param “* * * * *” as first argument. If I can post anything else, please let me know.
which immediately started several Pipelines after restarting gitlab. Also, a new Pipeline is started again after pushing.
Which brings me to the question:
How is sidekiq-cluster to be started correctly? Why this “* * * * *” [1]? Looking at the githib page of the project it seems abandonded, at least they suppose to use sidekiq-pool instead. Is sidekiq-cluster really the new way of starting the process?
Thanks again, Jan
[1] the command startup reads sidekiq-cluster “* * * * *” …; specifing the config file is not even an option to the tool but somehow it reads the file…
