You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
GitLab topic filters are case-sensitive on project topics #1388
GitLab connection topic filters normalize configured topics to lowercase, but compare them against project topics without normalizing the project side. A project topic like Backend does not match a config topic or glob such as backend.
Reproduction
Evaluate GitLab project filtering with include.topics: ["backend"] and a project whose API response includes topics: ["Backend"].
Expected
Topic include/exclude matching should be case-insensitive and symmetric between configured topics and project topics.
Actual
Configured topics are lowercased, while project topics retain their original case, so mixed-case GitLab topics can fail otherwise matching filters.
Impact
GitLab sync can unexpectedly include or exclude repositories when GitLab projects use mixed-case topics.
Hi @DivyamTalwar, thanks for the clear reproduction. I’d like to work on this if it’s available for an external contribution.
I’ll first reproduce the mismatch using a GitLab project topic such as Backend with a configured backend filter. Then I’ll add regression coverage for exact and glob-based include/exclude filters, normalize project topics at the same comparison boundary as configured topics, and verify that behavior for other providers remains unchanged.
Could a maintainer confirm that this is the intended direction?
Activity
dubeyharshit0605 commentedon Jul 22, 2026
Hi @DivyamTalwar, thanks for the clear reproduction. I’d like to work on this if it’s available for an external contribution.
I’ll first reproduce the mismatch using a GitLab project topic such as Backend with a configured backend filter. Then I’ll add regression coverage for exact and glob-based include/exclude filters, normalize project topics at the same comparison boundary as configured topics, and verify that behavior for other providers remains unchanged.
Could a maintainer confirm that this is the intended direction?