🐛 Bug Report: 1.27 GitLab discovery regression when using fallbackBranch other than master

[jwnmulder]

📜 Description

Since Backstage 1.27, gitlab discovery is failing to find multiple projects during discovery.

The following configuration in Backstage 1.26 will find GitLab projects that have their default branch set to 'develop'. The same configuration using Backstage 1.27 will only find projects that have a catalog-info.yaml file in the same repository as is set by fallbackBranch

catalog:
  providers:
    gitlab:
      gitlab-instance:
        host: gitlab.host
        fallbackBranch: main
        schedule:
          frequency: { minutes: 30 }
          timeout: { minutes: 10 }

The regression is introduced in a70377d where

      const project_branch =
        this.config.branch ??
        project.default_branch ??
        this.config.fallbackBranch;

in plugins/catalog-backend-module-gitlab/src/providers/GitlabDiscoveryEntityProvider.ts was changed to

    const customFallbackBranch =
      this.config.fallbackBranch !== 'master'
        ? this.config.fallbackBranch
        : undefined;

    const project_branch =
      this.config.branch ??
      customFallbackBranch ??
      project.default_branch ??
      this.config.fallbackBranch;

Here, customFallbackBranch takes precedence over the default branch set in GitLab on project level.

👍 Expected behavior

Find all GitLab projects where a catalog-info.yaml file exists in the default branch of that repository

👎 Actual Behavior with Screenshots

catalog info Processed 0 from scanned 0 projects. target=GitlabDiscoveryEntityProvider:gitlab-instance class=GitlabDiscoveryEntityProvider taskId=GitlabDiscoveryEntityProvider:gitlab-instance:refresh taskInstanceId=ec82cb6d-4138-49d9-92f7-2d0e5ea8ffc4

👟 Reproduction steps

Using an on-prem GitLab, configure multiple repositories with different default branches. In addition, configure backstage so that fallbackBranch is set to another value than master, e.g. main

📃 Provide the context for the Bug.

On-prem GitLab instance

🖥️ Your Environment

No response

👀 Have you spent some time to check if this bug has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

None

[Rugvip]

Thank you for reporting!

@elaine-mattos since you're probably the one most familiar with the new setup, I wanted to check whether you think there's a simple fix here?

[elaine-mattos]

Hi, I'll take a look at it soon, no later than tomorrow!

[elaine-mattos]

Hi @Rugvip ,

we were testing a very specific use case at our installation and I forgot to remove this piece of code, sorry!
I have fixed it by removing the custom fallback branch and improved the tests a little bit, so that such bugs won't happen again.
Here's the PR: #24838