Closed jwnmulder closed 1 week ago
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?
Hi, I'll take a look at it soon, no later than tomorrow!
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: https://github.com/backstage/backstage/pull/24838
π 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 byfallbackBranch
The regression is introduced in https://github.com/backstage/backstage/commit/a70377d3e1902480cbae14b2c7a861514f0a61ff where
in
plugins/catalog-backend-module-gitlab/src/providers/GitlabDiscoveryEntityProvider.ts
was changed toHere,
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
π 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 thanmaster
, 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?
π’ Have you read the Code of Conduct?
Are you willing to submit PR?
None