denis256 notes and projects

ingestr v1.0.41 was published on June 23, 2026, with a practical set of connector and loader changes. The main user facing change is a new GitLab source, backed by Braze user_data work and an optimization for BigQuery merge partition pruning.

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

GitLab lands as a new source

The clearest addition in this release is GitLab source support. The release notes list both a merged GitLab source pull request and a direct entry for adding the new source.

That matters because ingestr is usually judged by what systems it can move data out of without custom glue code. GitLab is a common operational system for engineering teams, so native source support can remove one more small script from the data path. The notes do not list the exact tables, fields, or URI options, so this is a release where users should check the connector docs or test with a small sync before wiring it into scheduled jobs.

For operators, the safe read is simple. If GitLab data was blocked on source support, v1.0.41 is the first tag in these notes that says the source exists. Treat the first run like any new connector rollout: start narrow, confirm schema shape, then expand.

Braze user data gets attention

Braze also gets a visible update through feat(braze): add user_data table (segment user export). That points to a new user_data table focused on segment user export, which is useful when Braze data needs to land in a warehouse beside events, campaign data, or downstream audience models.

There is also follow up work named fetch-users-then-subscribe, plus a review item on user_data. The release notes are short, so it would be wrong to claim more behavior than they state. Still, the shape is clear enough: this tag adds a new Braze data surface and includes cleanup around that path.

This is the kind of release detail that matters more to people maintaining jobs than to people reading a changelog casually. A new table changes what can be loaded, but it can also change what needs to be monitored. Check row counts, schema drift, and expected segment coverage when adding user_data to an existing Braze pipeline.

BigQuery merge pruning should reduce wasted work

The loader side gets a targeted BigQuery improvement: Optimize BigQuery merge partition pruning. If you run ingestr into partitioned BigQuery tables, this is the operational change to notice.

Partition pruning is not a glamorous feature, but it is where warehouse jobs either stay tidy or quietly scan too much data. The release note does not include benchmark numbers, so there is no honest claim to make about cost or runtime. The practical point is narrower: merge behavior for BigQuery partitioned targets received attention in this tag.

That is worth testing on real tables. Compare a normal merge load before and after the upgrade, especially on large partitioned destinations. Look at bytes processed, affected partitions, and job duration. If those numbers move in the right direction, this release gives you a concrete reason to upgrade beyond the new source work.

Internal audit and review cleanup

Not every line is a user feature. The changelog also includes add license audit lock, lint cleanup, retry logic, and a Greptile review item on user_data.

The license audit lock is mostly project hygiene, but it is useful hygiene. It makes dependency and license checks more repeatable, which helps maintainers avoid vague supply chain drift. The lint and review entries are the usual cleanup around feature work.

The retry logic entry is brief. Since the notes do not say which path it affects, treat it as a general hardening signal, not a promise about a specific connector. That is annoying if you need exact behavior, but it is better than reading too much into a one line changelog.

Where to get it

• Release page: GitHub release page
• Project repo: project repository
• Tag: v1.0.41