What does this MR do?
This fixes a bug introduced by https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8084.
When we try to update a build, we load it's representation to the memory,
in between another update can happen by another Runner.
Since we use optimistic locking we will receive an exception stating
that our copy of the object is old (
This exception makes us return
Since we received
nil we assume that we did not found a new build, so, the build queue is empty.
However, this is not true, because we only failed to update the existing build.
Runner then will receive the latest value of runner queue (after change),
and next time when we ask the
builds/register.json we will hit the happy path of processing,
assuming that there were no changes to build queue since the last time.
This bug affects GitLab Runners from 1.9.0-rc5 to 1.10.x
Does this MR meet the acceptance criteria?
Changelog entry added
Tests added for this feature/bug
What are the relevant issue numbers?