ingestr v1.0.42 - GitLab Source Fan Out

ingestr v1.0.42 was published on June 24, 2026, with a narrow GitLab source release centered on project scoped extraction. The main operator visible change is per project fan out for GitLab issues and merge requests, paired with simpler pagination and a new project users table. It is not marked as a prerelease.

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

The clearest change in ingestr v1.0.42 is the GitLab source moving issues and merge requests through per project fan out. The release notes do not spell out the exact call graph, but the named change is specific enough for operators to care. Extraction is now framed around project level traversal for those two datasets, not just a broad source pass that hides project boundaries in the connector.

That matters for reconciliation. GitLab issues and merge requests are usually checked by project, because ownership, review routing, and incident triage all tend to start there. A project fan out shape gives pipeline owners a cleaner place to compare counts, isolate missing rows, and reason about failed source reads. It may also change row arrival order, so downstream tests should assert keys and counts instead of assuming extract order.

The changelog adds a GitLab source users table and a related change to make users replace. Read that as the schema signal in this release. User membership data is no longer just context around issues or merge requests. It is now visible as a project shaped dataset that downstream models can join against.

The replace behavior is also important. For access and membership tables, the common question is who has access now, not how many times the same user appeared in repeated source reads. A replace style load fits that current state model better than an append only stream. It does mean consumers should inspect marts that join GitLab users to issues, merge requests, ownership maps, or audit views. If a warehouse already has a hand built users table, check names, keys, and write targets before the scheduled job runs.

The release notes also call out simplified pagination and error handling. There is not enough detail in the published notes to claim a new retry policy, a new exception type, or a different backoff rule. The narrower point is still useful: the GitLab source traversal changed in the same release that touched page iteration and failure reporting.

Treat the first run after upgrade as a data validation run. Compare counts for issues, merge requests, and users against the previous successful extraction. Scan logs for changed error text if alert rules match exact messages. This kind of maintenance is easy to underrate until a monitor depends on a string that moved, or a page token bug shifts a slice of rows between runs.

Most of v1.0.42 is GitLab source work. The notes mention a source refactor, project users, project fan out, pagination cleanup, error handling, and a small documentation change. They do not claim destination changes, CLI changes, scheduler changes, or new non GitLab sources.

That is useful for upgrade planning. Jobs that do not use the GitLab source should not expect material behavior from this tag based on the published release notes. Jobs that do use GitLab should test with real projects that include issues, merge requests, and users. A process smoke test that only checks exit status will miss the actual risk in this release, which is the shape and completeness of extracted GitLab data.