ingestr v1.0.42 - GitLab Source Users and Fan Out

ingestr v1.0.42 was published on June 24, 2026 with a focused GitLab source update for extraction jobs. The main operational change is per project fan out for GitLab issues and merge_requests, alongside a new project users table and pagination cleanup around the same source.

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

The release notes point to a GitLab source refactor and a per project fan out path for issues and merge_requests. For data teams, that is the part to read first. Project scoped fan out can change how extraction work is divided, how API calls are paced, and where partial failures show up.

The notes do not publish a migration guide or config key change, so this should not be treated as a confirmed CLI or YAML change. Still, platform operators should watch GitLab jobs that pull many projects. A shift toward project level work can alter request patterns and destination write order, even when the end tables keep the same basic purpose.

This is also where pagination cleanup matters. In GitLab sources, pagination is not a cosmetic detail. It controls whether backfills miss late pages, repeat pages, or stop early when an API response shape differs by endpoint.

v1.0.42 adds a GitLab source users table, according to the release notes. The changelog also says make users replace, which is a small phrase with real warehouse implications.

For analytics, project user data is often the join point between issue activity, merge request review, and team reporting. A direct table avoids forcing every downstream model to infer users through activity records. It also gives dbt or SQL models a cleaner place to attach role, membership, or identity mapping logic.

The replace behavior is worth checking in jobs that expect append only history. The notes do not describe the table schema, primary key, or destination semantics. Treat the first run after upgrade as a validation point: inspect row counts, duplicate keys, and whether deleted or renamed GitLab users behave as expected.

Two changelog entries are simply error handling and errors. That is not enough detail to claim a fixed failure mode, but it is enough to tell operators where to pay attention after upgrade. If previous GitLab source runs failed with unclear messages, v1.0.42 may change what gets surfaced in logs.

For scheduled ELT, better error surfaces are useful only if they preserve the failing endpoint, project, and page context. After upgrading, compare one successful run log and one forced failure, if you can do that in a staging runner. Look for whether GitLab project identifiers and table names remain visible.

This is a narrow release. There is no broad connector expansion here, and no release note that says every source is affected. The signal is GitLab source reliability and observability, not a platform wide behavior change.

The final changelog item is smol doc, which suggests a documentation touch rather than a feature. That matters because several code changes here have operator implications but limited public explanation. If you maintain repeatable ingestion jobs, read the GitHub release page and then test against your own GitLab project set.

Keep the validation practical. Run a small project set, then a large one. Compare counts for issues, merge_requests, and project users against the previous run. Watch API rate behavior if your GitLab instance has strict limits.

This is not marked as a prerelease. The metadata lists prerelease as false, and the release name is v1.0.42.

No breaking change is stated in the notes. Even so, this is a source behavior release, so do not treat it like a doc only update. The project users table and replace behavior deserve a warehouse check before using the output in reporting or access analysis.

• Release page: GitHub release page
• Repository: project repo
• Tag: v1.0.42