Moved runner from specific to shared, now job gets stuck

I’m using a self-managed GitLab 12.6.4 (eek).

Earlier I successfully set up a project-specific runner and had it run a CI workflow on commit.

After this test I wanted to make the runner available to other projects, so I removed it from the project, then went into my admin panel to find the global registration token, and re-registered it. It showed up with [shared][locked] states.

Yet the same project I tested earlier gets stuck now. I think it cannot find a suitable runner.

This job is stuck because the project doesn’t have any runners online assigned to it.

The meaning of [shared] is given as, “Runner runs jobs from all unassigned projects,” so this sounds like I do not need to do any configuration to assign the project to this runner. And if I checked the project’s CI/CD settings, shared runners are enabled and the runner shows up under “Available shared Runners: 1.”

I also moved the runner out of [locked] state in case that would help, but still did not get the pending job unstuck. (Please tell me if I should re-enable it.)

The last bit is when I registered the shared runner, I gave it a new tag, arm64. Then I modified my .gitlab-ci.yml to specify that tag. Perhaps the way I did it doesn’t work?

  image: ubuntu:bionic
    - arm64

  - arch
  - uname -a
  - find .
  - apt-get update && apt-get install -y build-essential

  stage: build
    - echo '#include <stdio.h>' >> main.c
    - echo 'int main() { printf("hello world\n"); return 0; }' >> main.c
    - gcc -o main main.c
    - ./main

I did get it unstuck by using:

  stage: build
    - arm64

But I don’t know why the default tags didn’t work.

1 Like