Package: gitlab Version: 13.2.3-2+fto10+1 Severity: normal Dear Maintainer,
Since the upgrade to above mentioned version, artifact uploads from gitlab runners fail with an error 500. Snippet from the job log: --- Uploading artifacts... time="2020-08-18T19:42:06+02:00" level=error msg="Docker executor: prebuilt image will be loaded from /var/lib/gitlab-runner." Runtime platform arch=amd64 os=linux pid=32578 revision=13.0.1 version=13.0.1 debian/pkg/*: found 6 matching files WARNING: Uploading artifacts to coordinator... failed id=3633 responseStatus=500 Internal Server Error status=500 Internal Server Error token=00000000 WARNING: Retrying... context=artifacts-uploader error=invalid argument WARNING: Uploading artifacts to coordinator... failed id=3633 responseStatus=500 Internal Server Error status=500 Internal Server Error token=00000000 WARNING: Retrying... context=artifacts-uploader error=invalid argument WARNING: Uploading artifacts to coordinator... failed id=3633 responseStatus=500 Internal Server Error status=500 Internal Server Error token=00000000 --- In the production.log I found the following stack trace: --- Started POST "/api/v4/jobs/3633/artifacts?artifact_format=zip&artifact_type=archive&expire_in=12+hours" for 1.2.3.4 at 2020-08-18 19:42:06 +0200 NoMethodError (undefined method `empty?' for 201:Integer): lib/gitlab/middleware/read_only/controller.rb:51:in `call' lib/gitlab/middleware/read_only.rb:18:in `call' lib/gitlab/middleware/same_site_cookies.rb:27:in `call' lib/gitlab/middleware/basic_health_check.rb:25:in `call' lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call' lib/gitlab/middleware/request_context.rb:23:in `call' config/initializers/fix_local_cache_middleware.rb:9:in `call' lib/gitlab/metrics/requests_rack_middleware.rb:60:in `call' lib/gitlab/middleware/release_env.rb:12:in `call' --- Unfortunately, the call stack ends here. As far as I can tell, this is only middelware code, and I was not able to easily find the problematic usage of `empty?` anywhere nearby this code. Is there a way to increase the number of lines in the stack trace? Although the CI jobs fails with this error, the artifacts themselves are still uploaded successfully and can be viewed/downloaded in the gitlab UI. So, this only seems to be a minor problem in the artifact logic. The particular runner instance was at version 11.2.0+dfsg-2 and worked with the previously installed gitlab version (13.1.6-1+fto10+1). Upgrading the runner to version 13.0.1+dfsg-1 did not change the situation. Thank you very much! Best, Maximilian
