Skip to content

Update post receive worker so it logs a unique JID in sidekiq

Instead of

2016-04-14T03:07:32.373Z 5285 TID-osycgmlyo PostReceive JID- INFO: start
2016-04-14T03:07:32.374Z 5285 TID-osycgmlyo PostReceive JID- INFO: arguments: [...]
2016-04-14T03:07:32.534Z 5285 TID-osycgmlyo PostReceive JID- INFO: done: 0.161 sec

Have this log

2016-04-14T03:07:32.373Z 5285 TID-osycgmlyo PostReceive JID-54b0b2f6616cae37e3e87f8a INFO: start
2016-04-14T03:07:32.374Z 5285 TID-osycgmlyo PostReceive JID-54b0b2f6616cae37e3e87f8a INFO: arguments: [...]
2016-04-14T03:07:32.534Z 5285 TID-osycgmlyo PostReceive JID-54b0b2f6616cae37e3e87f8a INFO: done: 0.161 sec

This way sidekiq can Log a unique JID in the sidekiq.log for PostReceive. So when parsing the logs (with logstash for example) you know it belongs to that unique job.

This puts the logs in a uniform manner like the other workers that are pushed to redis (which do have a JID) For example the ProjectWebHookWorker

2016-04-14T03:13:07.917Z 5285 TID-osycsh7z0 ProjectWebHookWorker JID-800085fb3cf7241fdeecc6ec INFO: start
2016-04-14T03:13:07.918Z 5285 TID-osycsh7z0 ProjectWebHookWorker JID-800085fb3cf7241fdeecc6ec INFO: arguments: [...]
2016-04-14T03:13:12.500Z 5285 TID-osycsh7z0 ProjectWebHookWorker JID-800085fb3cf7241fdeecc6ec INFO: done: 4.583 sec

Merge request reports