Fails when GPG key of https://packages.gitlab.com/runner/gitlab-runner is expired
fabriceverkor opened this issue · comments
GPG key of https://packages.gitlab.com/runner/gitlab-runner repo is expired, preventing to update cache :
apt-get update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Hit:3 https://download.docker.com/linux/debian bookworm InRelease
Hit:4 http://deb.debian.org/debian bookworm-updates InRelease
Hit:5 https://packages.wazuh.com/4.x/apt stable InRelease
Get:6 https://packages.gitlab.com/runner/gitlab-runner/debian bookworm InRelease [23.4 kB]
Err:6 https://packages.gitlab.com/runner/gitlab-runner/debian bookworm InRelease
As first task in /etc/ansible/roles/riemers.gitlab-runner/tasks/install-debian.yml is APT cache update, playbook fails, even with gitlab_runner_skip_package_repo_install=false
You may change order of tasks in /etc/ansible/roles/riemers.gitlab-runner/tasks/install-debian.yml or test key validity to decide if https://packages.gitlab.com/runner/gitlab-runner repo should be reconfigured.
Seems this message did not get a lot of love. This does not mean it was not seen but time wise might not have made it to proper attention. This is just the clean up action ;)
you could add a part it checks the GPG key, i was usually against doing updates in a role since you could have a role that updates all in a higher level thus having an update multiple times. But communicty liked the idea ;p
I also have this issue.
I currently do not add the gitlab-runner APT repo anywhere else and was hoping that whatever APT repo changes there are, it is managed by this role.
Could remove the repo part all together again ;p Also some company's have firewalls/proxy's and it might not work anyways for them too. My time is limited so i can't dive into this at this moment.
Could remove the repo part all together again ;p Also some company's have firewalls/proxy's and it might not work anyways for them too. My time is limited so i can't dive into this at this moment.
Thanks for the quick answer!
For now I will use my own APT repo logic then. Yeah for the firewall stuff I can see that the issue authors gitlab_runner_skip_package_repo_install=false could work for orgs with locked down rules. So the repo init is skipped altogether.
Yeah thats an excellent idea to have. Personally i would default that to false, since repo's change, keys change etc etc, it would be yet another item to maintain. Also get your point.
Seems this message did not get a lot of love. This does not mean it was not seen but time wise might not have made it to proper attention. This is just the clean up action ;)