Add configuration option to register runner with run_untagged=false.

GitLab has an option to configure a runner so it will not run untagged jobs (run_untagged=false). The merge request discussion for that change mentions that the Runner will be updated to support this configuration option. Has that happened already and isn't documented, or is it still something that needs to be done?

I desperately need this capability so the runners can register as tag-only when they are created. My runners are running in Docker containers and register themselves whenever a new container spins up. The only workaround I can see is injecting GitLab admin credentials in my runner container so it can use the API to reconfigure the runner after it registers. I'd very much prefer not to have to go that route.

Ideally, config.toml could be updated to support one or both of:

[[runners]]
  run_untagged = true|false
  [runners.XXX]
    run_untagged = true|false

Would be great to have this as a CLI option as well for the "gitlab-runner register" function.

Added feature proposal label

@tmaczukin since GitLab supports this, I'm going to suggest we get it done for v1.8 at the latest :)

@dominik.nuszpl when you say "as a CLI option", do you mean when doing "gitlab-ci-multi-runner run", etc?

@nick.thomas: @dominik.nuszpl is proposing to add a --run-untagged=false flag to the gitlab-runner register, not gitlab-runner run command. Thanks to this we could register the new runner which would be from the beginning configured with disabled run untagged jobs feature.

@mrburrito The decision "which runner should be used for a job" is made in GitLab CE/EE, not in the Runner. And because of this I don't think that adding such option to config.toml is the way to go. I would rather add the register option suggested by @dominik.nuszpl (and update the registration API if needed). I think this should also resolve your problem: you would only need to update the registration script with some --run-untagged=false flag.

@tmaczukin yep. the --run-untagged flag would solve my issue.

This would be very helpful for me too, doing this manually is a real pain in the butt

This is a huge pain for us right now. We've got preconfigured AMIs with build runners on them, but when we scale up, we have this one manual step of checking that box. Putting it in the CLI would help a TON!

Added ~879635 label

mentioned in issue #1981 (closed)

changed milestone to %v1.10

+1 for CLI option.

+1, we have a lot of runners that serve different purposes with different access levels

I have been working on automation of the gitlab-runner vi system and I have a few issues around the default settings on the ci picking up untagged jobs. trouble is I have no way of stopping this from the registration.

can we have a --run-untagged=false please? At the moment I have to login to the GUI and disable them

@stephen.cooke.psycle I do something like this. It will require an admin token and I run it after my runner registers. Pretty lame but it works for now. I didn't see a way of searching for the runner ID with its token ID.

      #!/bin/sh
      PRIVATE_TOKEN=${private_token}
      GIT_HOST=<your host>
      TOKENS=`grep token /home/gitlab-runner/.gitlab-runner/config.toml  | awk '{print $3}' | cut -f2 -d\"`
      RUNNERS=`curl -s -k --header "PRIVATE-TOKEN: $PRIVATE_TOKEN" https://$GIT_HOST/api/v3/runners/all?per_page=250 | jq .[].id`
      for token in $TOKENS; do
        for runner in $RUNNERS; do
          thistoken=`curl -s -k --header "PRIVATE-TOKEN: $PRIVATE_TOKEN" "https://$GIT_HOST/api/v3/runners/$runner" | jq -r .token`
          if [ "$thistoken" == "$token" ]; then
            echo Setting untagged flag
            curl -s --request PUT -k --header "PRIVATE-TOKEN: $PRIVATE_TOKEN" "https://$GIT_HOST/api/v3/runners/$runner" --form "run_untagged=false" | jq
          break
          fi
        done
      done

mentioned in merge request !438 (merged)

I have a build working with cli support for this in !438 (merged) (uses --run-tagged-only) -- looking for comments/review...

@matt-deboer I'll check it out tomorrow! Thanks!

I'm closing this since !438 (merged) (thanks @matt-deboer!) is merged into master and will be included in v1.10

closed