Shared Runners setting is being disabled on projects intermittently

Summary

Customer is reporting that their GitLab.com shared runners setting is being disabled on projects that aren't actively being developed. When the customer decides to make a change after X days/months and try to run their pipeline, the jobs aren't picked up due to shared runners being disabled.

Steps to reproduce

  1. Develop a project with GitLab.com shared runners enabled
  2. Wait after X days to submit a commit, then run a pipeline
  3. Job is not picked up
  4. Shared Runner setting disabled.

Example Project

What is the current bug behavior?

Shared runners setting are disabled on inactive project.

What is the expected correct behavior?

Setting should stay enabled in case the project becomes active again.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:check SANITIZE=true)

(For installations from source run and paste the output of: sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)

(we will only investigate if the tests are passing)

Possible fixes

Ensure that settings remain enabled for projects that are not actively being developed.

Edited by Gina Doyle