ingestr v1.1.34 - ARM64 Container Images

ingestr v1.1.34 was published on 18 August 2026. The tag is a container packaging release, not a source or destination release. CI now publishes linux/arm64 images next to the existing linux/amd64 images, which previously left ARM Kubernetes nodes unable to schedule the published tag.

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

The GitHub release page lists two commits. Merge 30b735c5bdb491b3018074ec239d1ac7b2e9c9df brings in pull request 1103 from the docker-arm64-images branch. The functional change is fa95cae9af95123bcd7c3e89f38cbdc28a597b76, ci: publish linux/arm64 container images.

Before this tag, .github/workflows/release.yml passed platforms: linux/amd64 into depot/build-push-action. The same line now reads platforms: linux/amd64,linux/arm64. .github/workflows/tests.yml gets the same platform list with push: false, so an ARM build break fails the pull request instead of the release job.

The image name in that workflow is ghcr.io/bruin-data/ingestr, tagged from github.ref_name. A pull of ghcr.io/bruin-data/ingestr:v1.1.34 hits a multi-arch index. kubelet and Docker select the blob that matches the node. The Dockerfile was not rewritten. The commit message says it is already architecture agnostic: a native CGO build on the multi-arch golang and debian base images.

GoReleaser already shipped a CGO linux/arm64 binary. The container publish path was the lagging piece. Depot builds each platform on a native builder, so the second platform does not sit behind QEMU in CI. The patch itself is 13 insertions and 3 deletions in release.yml, plus a one line platform edit in tests.yml. An amd64 only image on an arm64 node does not schedule. A multi-arch index with a real linux/arm64 variant does.

This is linux/arm64, not Darwin. A Mac still runs the image inside a Linux VM. The useful case is Linux ARM workers: Graviton nodes, Ampere nodes, and native ARM CI runners that used to pull amd64 and emulate it.

Publishing a second platform without booting it is how a broken ARM variant ships under a familiar tag. The docker-test job in .github/workflows/release.yml is now a matrix.

fail-fast is false. The amd64 leg still runs on depot-ubuntu-latest. The arm64 leg runs on ubuntu-24.04-arm. Each runner is native, so docker pull of ghcr.io/bruin-data/ingestr:v1.1.34 resolves that architecture from the index.

The smoke path is the same on both legs. After the pull, the job runs the image, then runs a tiny ingest from a CSV file into DuckDB with --source-uri and --dest-uri. That checks that the container starts and that the CLI can read a file and write a DuckDB database. It does not exercise Snowflake, BigQuery, or CDC.

Forks that copy this workflow inherit two runner labels: depot-ubuntu-latest and ubuntu-24.04-arm. Without an ARM runner that matches the second label, the matrix sits queued or fails. That is the cost of testing the variant instead of only listing it in platforms.

If you already ran the image on ARM with docker run --platform linux/amd64, QEMU user emulation sat on every extract. A native linux/arm64 blob removes that. The tag digest is now an index, not a single amd64 image. Jobs that pinned an older amd64 only digest still have that older blob until the pin moves.

No source, destination, or ingest CLI behavior is listed in the notes. There is no new --source-uri scheme, no schema migration, no CDC fix. If a pipeline is waiting on a connector bug, v1.1.34 is the wrong tag to expect it from.

The GoReleaser binary path is unchanged in the notes. Internal CI wiring moved to a matrix. That is an internal refactor of how images are tested, with one operator visible result: ARM nodes can pull a native image from the same tag name they already use on amd64. Read the two commits if you vendor the workflows.

This is not a prerelease. The notes do not advertise a CLI break.

If a workload pins by digest, keep that pin until you choose to move. The v1.1.34 tag is a multi-arch index. Update the digest if you pin tags and you want the ARM variant in cluster.

On ARM nodes, drop docker run --platform linux/amd64 and any node taint that existed only to dodge the missing variant. Confirm kubernetes.io/arch is arm64 and that the runtime is not still forcing amd64. On amd64 nodes the published variant remains linux/amd64. Mixed clusters pull per node. A DaemonSet of this image is not one architecture after the upgrade.

Pull the tag and inspect the local variant:

docker pull ghcr.io/bruin-data/ingestr:v1.1.34
docker image inspect ghcr.io/bruin-data/ingestr:v1.1.34 --format '{{.Architecture}}'

That inspect shows the blob on disk, not the full index. On an ARM Linux host the value should be arm64.