Gitlab CI fails with 0 jobs only on coworker's branches

I have a Gitlab CI script that only builds the application. I have 4 job when 3 of them should only be executed on the main branch.

Everytime my coworker’s pushes a commit, it fails the pipeline with the following message:

0 jobs for branchname

But when I push my commits on any branch or when I merge my coworker’s branch on main, the CI works perfectly.

I tried to look at my coworker’s gitlab CI file and it seems OK.That version of the file has worked before. Gitlab tells me it’s a valid YAML file when I open it. I’ll copy paste it below. The only job that should be running is build_service_32.

stages:
  - build

build_daemon_64:
  stage: build
  tags:
    - linux
  only:
    - main
  image: gcc
  before_script:
    - apt-get update -qq
    - apt-get install -y build-essential
    - apt-get install -y cmake
    - apt-get install -y libxtst-dev
  script:
    - cd daemon
    - ./build.sh    
  artifacts:
    paths:
      - daemon/cvpd    

build_daemon_32:
  stage: build
  tags:
    - linux
  only:
    - main
  image: i386/ubuntu
  before_script:
    - apt-get update -qq
    - apt-get install -y build-essential
    - apt-get install -y cmake
    - apt-get install -y libxtst-dev
  script:
    - cd daemon
    - ./build.sh
  artifacts:
    paths:
      - daemon/cvpd

build_service_32:
  stage: build
  before_script:
    - apt-get update -qq
    - apt-get install -y build-essential
    - apt-get install -y cmake  
    - apt-get install -y mingw-w64
  image: mmozeiko/mingw-w64
  script:
    - cd service
    - chmod +x build_win32.sh
    - ./build_win32.sh
  artifacts:
    paths:
      - service/_build/win32/src/cvps.exe
#SOURCES: https://about.gitlab.com/blog/2018/10/24/setting-up-gitlab-ci-for-android-projects/
#         https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Android.gitlab-ci.yml
build_app:
  stage: build
  variables:
    ANDROID_COMPILE_SDK: "22"
    ANDROID_BUILD_TOOLS: "22.0.1"
    ANDROID_SDK_TOOLS:   "7583922_latest"
  image: openjdk:11
  only:
    - main
  cache:
    key: ${CI_PROJECT_ID}
    paths:
      - .gradle/
  before_script:
    - apt-get update -qq
    - apt-get install -y wget tar unzip lib32stdc++6 lib32z1
    - export ANDROID_HOME=$PWD/android-sdk-linux
    - export PATH=$PATH:$PWD/android-sdk-linux/platform-tools/
    - wget --output-document=android-sdk.zip https://dl.google.com/android/repository/commandlinetools-linux-${ANDROID_SDK_TOOLS}.zip
    - mkdir -p android-sdk-linux/cmdline-tools
    - unzip -d android-sdk-linux/cmdline-tools android-sdk.zip
    - mv android-sdk-linux/cmdline-tools/cmdline-tools android-sdk-linux/cmdline-tools/latest
    - echo y | android-sdk-linux/cmdline-tools/latest/bin/sdkmanager "platforms;android-${ANDROID_COMPILE_SDK}"
    - echo y | android-sdk-linux/cmdline-tools/latest/bin/sdkmanager "platform-tools" 
    - echo y | android-sdk-linux/cmdline-tools/latest/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS}" 
    # temporarily disable checking for EPIPE error and use yes to accept all licenses
    - set +o pipefail
    - yes | android-sdk-linux/cmdline-tools/latest/bin/sdkmanager --licenses
    - set -o pipefail
    - export GRADLE_USER_HOME=$(pwd)/app/.gradle
    - chmod +x ./app/gradlew
  script:
    - cd app
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/app/build/outputs/apk/debug/

we are facing the same issue

I have the same issue. Did you find any solution?

I have the same issue +1

Gitlab’s CI/CD scripting is abjectly awful, it’s trying way too hard to be like a cross between ansible and github workflows, manages neither, and instead acts as a stunning counterweight to everything gitlab has to offer.

On the one hand, bringing up and configuring runners is a breeze, on the other, building a simple cmake target for 2 platforms is going to cost you a week in therapy.

If you’ve used something like Jenkins in the past, it’s easy to overlook that gitlab builds from within the branch, so it uses all the tooling and the .yml from in the branch, rather than doing everything from Trunk.

With that in mind, you probably need to throw out everything in the yml in the branch and add some debug prints and baby-step thru each option and setting against the current documentation until you find where it stops working.

I wish I could say that the CI/CD scripting system is maturing, but in 2 years of using gitlab I’ve found it only became differently janky, and I think it will continue to be that way as long as they’re using yaml for it. Not hating on yaml, but this would actually be the perfect case for a Ruby DSL, but instead they’re beating a pythonic-approach into a mostly ruby ecosystem and a cluster**** ensues.

Anyone who has worked with a well setup Chef or Puppet system and then tried to revisit ansible knows exactly what I mean.

We are facing the same issue!
Any updates here?

Thanks!

@pavio @larienna - This sounds like a permissions issue or the /main branch is protected which is why one user can run the pipeline and another cannot.

I hope this helps!

-James H, GitLab Product Manager, Verify:Pipeline Execution

Thank you, @jheimbuck_gl !

Unfortunately, branch permissions not helped here.

I can run pipelines in the group of projects and it is working good.
In the same time I see in my account (https://gitlab.com/-/profile/usage_quotas) that I don’t used any CI/CD minutes:
“CI/CD minutes usage since Jan 01, 2023: 0 / 2000 minutes”

Other users can’t run pipelines and see in it accounts just:
“CI/CD minutes usage since Jan 01, 2023: 0 / Not supported minutes”

Sorry, but where I can see Usage Quotas that actually used for a group of projects?

Also, if a user with zero supported minutes try to run a pipeline, then GitLab asking for “User validation required” with a credit card.

@Pavlo,

We do the user check first when they attempt to run the pipeline to ensure they are validated. You can find more information about why we do this check in our blog post on preventing crypto mining abuse.

You can see group CI/CD Minute usage for groups in Menu > Groups > Settings > Usage Quotas. There’s more information about the minute usage in the documentation.

I hope this helps!

-James H, GitLab Product Manager, Verify:Pipeline Execution