ingestr v1.1.17 - OneLake Schema Evolution

ingestr v1.1.17, published on August 3, 2026, adds schema evolution for OneLake destinations. That is the main data pipeline change in this stable release; smaller updates bound CrateDB refresh work at five minutes and align release CI with pull request CI.

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

Schema evolution is now available for OneLake destinations. The scope matters: the changelog names OneLake specifically and does not claim equivalent behavior for every ingestr destination.

This should reduce the amount of manual intervention required when a source schema changes during a OneLake load. The release notes do not define which mutations are supported, how incompatible types are handled, or whether existing tables need preparation. Those details remain important for production jobs, so operators should exercise expected source changes against a staging destination before changing a schedule.

The release also does not list a configuration key, command flag, or migration step for the feature. Existing OneLake pipelines should therefore be checked with their current invocation and schema controls. Treat the new behavior as a destination capability that needs validation, not as a reason to remove schema monitoring from the pipeline.

Two changelog entries address REFRESH TABLE for CrateDB. The operation now has an explicit bound, and its timeout was raised to 5m. Together, these changes make the failure window easier to reason about while allowing a slow refresh more time to finish.

This is an execution control change, not a storage or query performance improvement. A refresh that needs more than five minutes can still time out. An outer task timeout below 5m can also terminate the job before the CrateDB limit is reached. Pipeline owners should compare this value with worker deadlines, retry policies, and scheduler limits rather than assuming the new timeout settles the entire failure budget.

The notes do not state whether timeout failures are retried or how partial work is reported. Logs and destination state should remain part of the runbook for any load that reaches REFRESH TABLE.

The release runner now matches the runner used for pull request CI. That narrows one source of variation between checks performed before merge and checks performed for a release. It is primarily a release engineering correction, but it matters to operators because packaging failures are easier to diagnose when both paths use the same runner class.

The changelog also records a merge from a branch named for a larger CI test runner. No CPU, memory, platform, or benchmark figures are included, so this should not be read as a runtime performance claim for ingestr itself.

No consumer action is described for the CI change. It does not alter a connector contract or destination schema. Its value is at build time: less environment variation between review and release makes a discrepancy easier to isolate to code or packaging rather than runner selection.

No breaking changes or migration steps are listed. The release is not marked as a prerelease.