What
Nothing in the connector build tooling validates that a connector's pinned connectorBuildOptions.baseImage actually defines the user the generated Dockerfile switches to. docker-images/Dockerfile.manifest-only-connector ends with USER airbyte, but that user only exists in newer source-declarative-manifest base images.
source-salesloft and source-aws-cloudtrail were still pinning source-declarative-manifest:5.15.0, which has no airbyte user. Their images built successfully and then failed at container start:
docker: Error response from daemon: unable to find user airbyte: no matching entries in passwd file
... non-zero exit status 125
That silently broke the pre-release publish workflow, the regression-test harness (failing at SPEC with Internal failure: true), and each connector's CI image/spec check. See #84349 and the fix in #84350.
Suggested guard
A metadata QA check or build-time assertion that fails with a clear message when the pinned base image does not define the user the generated Dockerfile selects — e.g. after building, run id airbyte (or getent passwd airbyte) in the image and fail with something like "base image <pin> does not define user airbyte required by Dockerfile.manifest-only-connector; bump connectorBuildOptions.baseImage".
A cheaper complementary check would be a metadata lint that flags base image pins more than N minor versions behind the current SDM pin, since the underlying problem was a stale pin that nobody noticed for ~a year.
Context
Filed as a follow-up from the /ai-fix workflow on airbytehq/oncall#13301, at the request of aaronsteers. Not urgent — the two affected connectors have been bumped — but the class of failure is easy to reintroduce and currently surfaces only as an opaque exit-125 at publish time.
Internal Tracking: https://github.com/airbytehq/oncall/issues/13302
What
Nothing in the connector build tooling validates that a connector's pinned
connectorBuildOptions.baseImageactually defines the user the generated Dockerfile switches to.docker-images/Dockerfile.manifest-only-connectorends withUSER airbyte, but that user only exists in newersource-declarative-manifestbase images.source-salesloftandsource-aws-cloudtrailwere still pinningsource-declarative-manifest:5.15.0, which has noairbyteuser. Their images built successfully and then failed at container start:That silently broke the pre-release publish workflow, the regression-test harness (failing at
SPECwithInternal failure: true), and each connector's CI image/spec check. See #84349 and the fix in #84350.Suggested guard
A metadata QA check or build-time assertion that fails with a clear message when the pinned base image does not define the user the generated Dockerfile selects — e.g. after building, run
id airbyte(orgetent passwd airbyte) in the image and fail with something like "base image<pin>does not define userairbyterequired by Dockerfile.manifest-only-connector; bumpconnectorBuildOptions.baseImage".A cheaper complementary check would be a metadata lint that flags base image pins more than N minor versions behind the current SDM pin, since the underlying problem was a stale pin that nobody noticed for ~a year.
Context
Filed as a follow-up from the
/ai-fixworkflow on airbytehq/oncall#13301, at the request ofaaronsteers. Not urgent — the two affected connectors have been bumped — but the class of failure is easy to reintroduce and currently surfaces only as an opaque exit-125 at publish time.Internal Tracking: https://github.com/airbytehq/oncall/issues/13302