[Integration][Gitlab-v2] Incremental sync POC

[raskinmaya]

Description

What -

Why -

How -

Type of change

Please leave one option from the following and delete the rest:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• New Integration (non-breaking change which adds a new integration)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Non-breaking change (fix of existing functionality that will not change current behavior)
• Documentation (added/updated documentation)

All tests should be run against the port production environment(using a testing org).

Core testing checklist

• Integration able to create all default resources from scratch
• Resync finishes successfully
• Resync able to create entities
• Resync able to update entities
• Resync able to detect and delete entities
• Scheduled resync able to abort existing resync and start a new one
• Tested with at least 2 integrations from scratch
• Tested with Kafka and Polling event listeners
• Tested deletion of entities that don't pass the selector

Integration testing checklist

• Integration able to create all default resources from scratch
• Completed a full resync from a freshly installed integration and it completed successfully
• Resync able to create entities
• Resync able to update entities
• Resync able to detect and delete entities
• Resync finishes successfully
• If new resource kind is added or updated in the integration, add example raw data, mapping and expected result to the examples folder in the integration directory.
• If resource kind is updated, run the integration with the example data and check if the expected result is achieved
• If new resource kind is added or updated, validate that live-events for that resource are working as expected
• Docs PR link here

Preflight checklist

• Handled rate limiting
• Handled pagination
• Implemented the code in async
• Support Multi account

Screenshots

Include screenshots from your environment showing how the resources of the integration will look.

API Documentation

Provide links to the API documentation used for this integration.

---

Note

Medium Risk
Incremental sync changes which entities are fetched on scheduled resyncs (cursor vs full/lookback behavior), including opened merge requests; incorrect cursor handling could miss updates or over-fetch until caught in testing.

Overview
Turns on incremental sync for the GitLab v2 SaaS integration and wires resync handlers to pass GitLab’s updated_after filter from Ocean’s incremental cursor.

A new gitlab/helpers/incremental.py layer uses ServerSideTimestampStrategy and helpers to merge the cursor into API params. Projects also get order_by=updated_at, and incremental filtering is skipped when project search queries are configured (GitLab list-endpoint limitation). Merge requests now apply the cursor to every state (including opened) on incremental runs; full resync still uses selector lookback only for non-opened states.

@ocean.on_incremental_resync is added alongside existing @ocean.on_resync for projects, issues, pipelines, merge requests, and deployments. Unit tests cover the incremental param builders.

^{Reviewed by Cursor Bugbot for commit bfdad4d. Configure here.}

[aws-amplify-eu-west-1]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-3606.d1ftd8v2gowp8w.amplifyapp.com

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit bfdad4d. Configure here.}

[cursor]

Inconsistent updated_after type in merge request params

Low Severity

build_merge_request_params stores updated_after as a raw datetime object on the full-resync path (line 56) but as a pre-formatted string via GITLAB_INCREMENTAL.merge_params on the incremental path (line 54). When httpx serializes a datetime via str(), it produces "2026-04-01 00:00:00+00:00" (space-separated), whereas the incremental path produces "2026-04-01T12:00:00Z" (T-separated). This inconsistency within a single function makes it harder to reason about the API contract and could cause subtle issues if GitLab's parser is strict about the format in some contexts. The lookback_updated_after datetime ought to be formatted the same way the strategy formats cursors.

Additional Locations (1)

• integrations/gitlab-v2/tests/helpers/test_incremental.py#L97-L102

 

^{Reviewed by Cursor Bugbot for commit bfdad4d. Configure here.}