denis256 notes and projects

ingestr v1.0.67 was published on July 7, 2026. This release is not marked as a prerelease, and the one clear user facing change in the notes is an adjustment to default metrics types. For teams that run ingestr in scheduled data movement jobs, this is the kind of small data shape change that deserves a quick schema and downstream check before the next run.

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

Default metrics types changed

The main changelog entry is the merge of PR #923 from a branch named adjust-default-metrics-types. The release notes do not spell out each field, so the practical reading should stay narrow: ingestr changed how some metrics defaults are typed.

That matters because metrics often sit between ingestion code and operational dashboards. If a default type moves from one representation to another, consumers may see different storage types, query behavior, or validation results. The release notes do not claim a broad connector change, so treat this as a metrics output concern first.

For operators, the check is simple. Run a small sync in a non production target, inspect the metric columns or event fields that your jobs rely on, and compare them with the shape from the previous v1.0.66 run if you still have it. Watch for strict sinks, typed warehouse columns, and alert rules that expect a specific numeric or string form.

The follow up commit stays on metrics

The third changelog line is update adjust metrics. It reads like a follow up to the same metrics type work, not a separate feature area. That is useful context because it keeps the release scope small. The visible notes point to one thread of work rather than a mixed release with connector fixes, CLI behavior changes, and dependency updates.

This is also where the short changelog is a limitation. There are no named sources, destinations, config keys, or CLI flags in the release notes. A careful post should not pretend otherwise. The action item is to test the metrics path your deployment actually reads, not to audit every ingestr connector.

Automation is present but not the story

The middle entry is a bot commit. The notes do not say what the bot changed. It may be release automation, generated metadata, or another maintenance task, but the public note does not give enough detail to call it a user visible change.

That still matters for release review. When a changelog combines a concrete feature branch with a generic automation commit, the safe assumption is that the operator impact comes from the named branch. In this case, that is the default metrics type adjustment. Keep the bot entry in mind if you compare source trees, but do not build an upgrade plan around it unless your own diff review shows more.

Upgrade notes

There are no breaking changes, migrations, or deprecations called out in the v1.0.67 notes. There is also no prerelease marker. This looks like a normal release with a narrow metrics adjustment.

The main risk is quiet type drift. Jobs may complete while dashboards, checks, or destination schemas react differently. If your ingestr usage feeds strict warehouse tables or alerting based on metrics payloads, test one representative job before promoting the version across all schedules.

Because the notes are sparse, avoid reading this as a broad runtime change. The better review path is local and concrete: check the metric fields you consume, check any typed destination tables, and check the reports that depend on those values. If nothing in your stack consumes ingestr metrics directly, this release should be a low noise update.

Where to get it

• Release page: ingestr v1.0.67
• Project repo: bruin-data/ingestr
• Tag: v1.0.67