ingestr v1.0.41 - GitLab Source and BigQuery Merge Pruning

ingestr v1.0.41 was published on June 23, 2026, with the most operator visible change being a new GitLab source for ELT jobs. The release also adds Braze user_data, touches BigQuery merge partition pruning, and is not marked as a prerelease.

The full release notes and downloads are on the GitHub release page.

The changelog lists a new GitLab source and the merge that brought it into the release. That matters for teams that already move SaaS product data through ingestr, because GitLab is often the source of issue, merge request, and pipeline state used in engineering metrics. The notes do not name the exact resources, auth scopes, or sync mode. Treat this as new connector surface, not a fully documented warehouse contract.

For platform operators, the key action is to validate the source with a small project first. Confirm rate limit behavior, job timing, and destination schema shape before adding it to a shared schedule. The release notes do not mention a migration, so this reads as additive.

Braze gets a user_data table tied to segment user export. This is a useful addition for data teams that model lifecycle, messaging, and consent data outside Braze, because it moves user level attributes into the same ingestion path as other marketing data.

The release notes also mention a review pass on user_data and a fetch users then subscribe change. That suggests the table work had at least one follow up pass around how user records are collected or prepared for export. The changelog is sparse, so consumers should inspect the resulting columns in a non production dataset before binding dbt models or BI dashboards to it.

BigQuery merge partition pruning is the clearest warehouse side change in v1.0.41. The title indicates that merge work can reduce the partition range considered during destination writes. For large partitioned tables, that is the difference between a merge that pays for broad table scans and one that stays closer to the changed time range.

There is no benchmark in the release notes. Operators should verify this through BigQuery job history after upgrade: bytes processed, slot time, and target partition count are the useful checks. If your ingestr jobs write into unpartitioned tables, this change is less relevant.

Two entries are mostly operational hygiene: a license audit lock and retry logic. The license audit lock is not a data feature, but it can make dependency review output less variable over time. That matters in CI systems that compare audit results between runs.

The retry logic entry has no named config key or failure mode attached to it. Read it as a reliability patch, not a new operator control. If you already wrap ingestr in an external scheduler, keep the scheduler level retry policy visible, because stacked retries can hide slow source failures.

The release notes do not call out breaking changes or migration steps. For this release, the safer upgrade check is a targeted run against GitLab, Braze user_data, and a partitioned BigQuery destination before moving shared schedules.