denis256 notes and projects

ingestr v1.0.42 was published on June 24, 2026. This regular release is mainly about the GitLab source, with per project fan out for issue and merge request reads, a GitLab users table, and error handling cleanup. For teams moving GitLab data into a warehouse with ingestr, this is the part to check before the next scheduled sync.

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

GitLab source refactor gets the attention

The changelog opens with a GitLab source refactor. The notes do not expose every internal detail, but the named work points to a cleaner source path for GitLab data. That matters for operators because GitLab extraction tends to touch several API shapes: projects, issues, merge requests, users, and pagination all need slightly different handling.

This release also carries a direct error handling entry. Sparse notes are annoying, but even a small error handling change is worth reading when the source is API heavy. If a pipeline fails on a GitLab response, the difference between a noisy stack trace and a clear source error can decide whether the fix takes five minutes or an hour.

Per project fan out for issues and merge requests

The most concrete behavior in v1.0.42 is per project fan out for issues and merge_requests, along with simpler pagination. That is a user visible area because issue and merge request syncs are usually the tables people notice first when GitLab reporting breaks.

This also changes how readers should think about source cost. Project scoped API calls can be easier to reason about than broad reads, but they can also make the number of requests follow the number of projects. For a small GitLab instance, this is likely invisible. For a large one, it is the thing to watch in job duration and GitLab API quotas after upgrade.

The pagination note is small, but it belongs in the same bucket. Pagination bugs rarely look elegant in production. They show up as missing rows, repeated rows, or slow jobs that spend too much time asking the same API for the next page. Simpler logic is a good direction, as long as row counts still match expectations.

GitLab users get a clearer path

The release adds a GitLab source users table and also says users now use replace behavior. The notes are short, so treat that as a signal to verify destination table behavior if GitLab users are already part of the sync plan.

This is a practical fit for user data. User records are normally consumed as a current state lookup in analytics jobs. When that table is used beside issue or merge request data, stale rows can make reports harder to trust. A replace style load can be the right choice for that shape, but existing downstream models should still be checked.

The changelog also includes a tiny documentation update. That is not the main story of the release, but it is useful when a source changes shape. Operators need the docs to match the table behavior, especially around sources that need API tokens and project scope decisions.

Upgrade notes

The release notes do not label this as breaking, and the release is not marked as a prerelease. Still, two items deserve a dry run. First, the users change may alter how destination rows are refreshed. Second, per project fan out may change the request pattern for GitLab API calls.

If GitLab syncs are large, run v1.0.42 against a non production destination first and compare row counts for users, issues, and merge_requests. Also check runtime and API quota usage. The code changes may be modest, but source connector changes can move load around in ways that only appear with real project counts.

Where to get it

• Release page: ingestr v1.0.42
• Repository: bruin-data/ingestr
• Tag: v1.0.42