feat(gitlab): add projectQuery support for dynamic project discovery #757
+187
−5
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes:#679
This PR addresses issue #679 by adding support for a new projectQuery configuration options in the GitLab integration. This allows users to dynamically select projects to mirror using raw GitLab API query strings, offering greater flexibility than statically defining groups or projects.
Approach
Schema Update:
Modified :
schemas/v3/gitlab.json to include the projectQuery property (an array of strings).
Updated the description and added examples to guide users on how to construct API query paths (e.g., groups/my-group/projects?include_subgroups=true).
Backend Implementation:
Updated
packages/backend/src/gitlab.ts
to process the projectQuery array.
Implemented
Deduplication: Implemented logic to ensure that if a project is returned by multiple queries (or overlaps with other config options), it is only added to the list once based on its Project ID.
Testing
I added comprehensive tests in packages/backend/src/gitlab.test.ts to fully validate the new functionality. This includes unit tests to ensure the parseQuery helper correctly converts query strings into the expected object parameters. I also added mocked integration tests by stubbing the gitbeaker GitLab client and the api.Projects.all method, verifying that getGitLabReposFromConfig invokes the GitLab API with parameters accurately derived from the configuration strings. The tests confirm that results returned from multiple queries are properly merged and deduplicated, while also ensuring that existing exclusion logic (such as exclude.topics) continues to work as intended. All tests were successfully verified by running yarn workspace @sourcebot/backend test src/gitlab.test.ts.