In der Standardkonfiguration legt GitLab-CI einen Cronjob an, welcher automatisch nach jedem Durchlauf ein „Done“ also Cronjob-Meldung an den lokalen Benutzer schickt. Wurde dieser – wie in der Installationsanleitung von GitLab-CI angegeben – korrekt konfiguriert, hat er eine gültige E-Mail-Adresse. Damit erhält man als Benutzer dieser E-Mail-Adresse jede Stunde eine Nachricht per E-Mail
Diese sieht folgendermaßen aus:
Betreff: Cron <gitlab_ci@domain.com> /bin/bash -l -c ‚cd /home/gitlab_ci/gitlab-ci && RAILS_ENV=production bundle exec rake schedule_builds –silent‘
Nachricht: Done
Das ist natürlich recht nervig, weshalb auch ich es abschalten wollte. Den Cronjob zu finden, war jedoch etwas schwieriger (man muss eben an der richtigen Stelle suchen), weshalb ich es hier einmal schnell erklären möchte.
Das Problem ist zwar bekannt, wird jedoch von GitLab nicht behoben:
The cron job shouldn’t emit anything to stdout. #449
Folgendermaßen muss man vorgehen, damit ein „standard output“ (stdout) nicht mehr per E-Mail versendet wird. Mit dieser Konfiguration erhält man bei Fehlern aber dennoch eine E-Mail, so wie es der Sinn der Benachrichtigung ist.
- Als der Benutzer einloggen, unter welchem GitLab-CI installiert wurde.
su gitlab_ci
- Den eigenen Crontab öffnen.
crontab -e
- Zeile 2 ändern.
Alt:0 * * * * /bin/bash -l -c 'cd /home/gitlab_ci/gitlab-ci && RAILS_ENV=production bundle exec rake schedule_builds --silent'
Neu:0 * * * * /bin/bash -l -c 'cd /home/gitlab_ci/gitlab-ci && RAILS_ENV=production bundle exec rake schedule_builds --silent' > /dev/null
Hier wird demnach der „standard output“ nach/dev/null
geschickt.
Das war es auch schon. Ab sofort sollte man keine E-Mails mehr erhalten.
Sofern sudo
installiert ist, kann man den Crontab auch mit einem Befehl öffnen: sudo -u gitlab_ci -H crontab -e