fix(amplify-category-api): migrate container templates off bitnami ECR Public + enforce TLS 1.2 on v1 searchable - #3494
Closed
sarayev wants to merge 3 commits into
Closed
Conversation
…R Public images Bitnami container images were removed from Amazon ECR Public Gallery (permanent removal June 10, 2026), so every `public.ecr.aws/bitnami/*` pull now fails. The customer-facing container templates scaffolded by the API category all referenced bitnami base images, which breaks `amplify add api` (container) docker builds for every customer on a cold cache. Migrate all four templates to the equivalent Docker Official Images published on ECR Public, which is the long-term alternative recommended in the AWS blog post and avoids embedding a customer-specific private ECR mirror URI into generated scaffolding: public.ecr.aws/bitnami/node:22 -> public.ecr.aws/docker/library/node:22 public.ecr.aws/bitnami/python:3.12-prod -> public.ecr.aws/docker/library/python:3.12 This also fixes a pre-existing container regression introduced in #3436, which changed the python base image from the valid tag `public.ecr.aws/bitnami/python:3.8-prod-debian-10` to `public.ecr.aws/bitnami/python:3.12-prod`. The bare `3.12-prod` tag does not exist in the bitnami python repo (bitnami `-prod` python tags always carry an OS suffix such as `-prod-debian-12`), so the python template build failed with a manifest-not-found error even before the ECR Public removal. The migration to `public.ecr.aws/docker/library/python:3.12` resolves both issues at once. Validated by building and running both the node (graphql-express) and python (dockercompose-rest-express) templates: `docker build` exits 0, `npm install`/`pip install` succeed on the new base images, and the containers start cleanly ("Listening on localhost:3000/graphql" and the Flask dev server on 0.0.0.0:5000). Ref: https://aws.amazon.com/blogs/containers/bitnami-image-removal-from-ecr-public/ --- Prompt: Fix the bitnami base-image removal breakage on the Gen1 branch release-api-plugin-stable, verify/complete the TLS 1.0 -> 1.2 OpenSearch/Elasticsearch fix, and detect a container regression introduced by recent commits (#3436, #3396). Use a git worktree for isolation, migrate bitnami refs per the AWS ECR-removal blog, document the regression root cause, close any remaining TLS-1.2 gap, and open a draft PR against release-api-plugin-stable.
…s effect on v1 searchable PR #3456 set `DomainEndpointOptions.TLSSecurityPolicy` to `Policy-Min-TLS-1-2-2019-07` on the v1 (Elasticsearch) searchable domain, but did not set `EnforceHTTPS`. On AWS::Elasticsearch::Domain the minimum TLS policy only governs the HTTPS endpoint, so without `EnforceHTTPS: true` the policy is not actually applied and the domain keeps reporting `Policy-Min-TLS-1-0-2019-07` — which is why amplify-cli e2e still saw a Policy-Min-TLS-1-0 CREATE_FAILED for v1 searchable after #3456 merged. The companion v2 (OpenSearch) fix in #3472 already pairs `enforceHttps: true` with `tlsSecurityPolicy: TLS_1_2`, so only the v1 path was left incomplete. Add `EnforceHTTPS: true` to the v1 domain's `DomainEndpointOptions` so the TLS 1.2 minimum is enforced, matching the v2 behavior. Update the existing unit test, which incorrectly asserted that `EnforceHTTPS` was undefined, to assert it is now `true`. Validated with `jest SearchableModelTransformer`: 7 passed, 7 snapshots passed, resources.ts at 100% coverage. See the AWS::Elasticsearch::Domain DomainEndpointOptions reference for the EnforceHTTPS / TLSSecurityPolicy contract in the CloudFormation docs. --- Prompt: Fix the bitnami base-image removal breakage on the Gen1 branch release-api-plugin-stable, verify/complete the TLS 1.0 -> 1.2 OpenSearch/Elasticsearch fix, and detect a container regression introduced by recent commits (#3436, #3396). Use a git worktree for isolation, migrate bitnami refs per the AWS ECR-removal blog, document the regression root cause, close any remaining TLS-1.2 gap, and open a draft PR against release-api-plugin-stable.
…e e2e init Add an idempotent, best-effort run-start step that guarantees the Gen1 deprecation-bypass placeholder app (DoNotDeleteAppToBypassGen1Deprecation) and its 'test' backend environment exist in each e2e shard's account + region before any `amplify init` runs, so the Gen1 end-of-life gate never blocks the suite and any prior cleanup-deletion is self-healed. The new ensureGen1PlaceholderApp(region) helper uses @aws-sdk/client-amplify: it paginates ListApps, creates the app via CreateApp only when missing, and creates the 'test' backend environment via CreateBackendEnvironment only when ListBackendEnvironments shows it absent. It is idempotent on both the app and the env, defaults region to process.env.CLI_REGION, relies on the ambient e2e credentials picked up by the SDK default provider chain, and swallows/logs all errors so an already-healthy run is never broken. It is wired as a Jest globalSetup hook (amplify-category-api-e2e-core/global-setup) in both Gen1 e2e packages (amplify-e2e-tests and graphql-transformers-e2e-tests) so it runs exactly once per shard before any test file or `amplify init`. The hook and helper live in standalone modules that avoid importing the heavy e2e-core barrel (and its native node-pty dependency), keeping globalSetup light. --- Prompt: Gen1 PR #3494 — add an at-test-start step that ENSURES the Gen1 placeholder app DoNotDeleteAppToBypassGen1Deprecation (+ backend env 'test') exists in each shard's account+region before `amplify init`, so the Gen1 EOL gate never blocks and cleanup-deletion is self-healed. Idempotent. Implement ensureGen1PlaceholderApp(region) using @aws-sdk/client-amplify, wire into the chosen run-start hook, build, commit (no --no-verify), push to fix/bitnami-ecr-removal-and-tls.
This was referenced Jun 26, 2026
Merged
Contributor
Author
sarayev
added a commit
that referenced
this pull request
Jun 26, 2026
…ies on v1 searchable (#3498) ## Description #### TLS 1.2 gap on the v1 (Elasticsearch) searchable domain PR #3456 set `DomainEndpointOptions.TLSSecurityPolicy` to `Policy-Min-TLS-1-2-2019-07` on the v1 Elasticsearch searchable domain but omitted `EnforceHTTPS`. On `AWS::Elasticsearch::Domain` the minimum TLS policy only governs the HTTPS endpoint, so without `EnforceHTTPS: true` the policy is never applied and the domain keeps reporting `Policy-Min-TLS-1-0-2019-07`. This is why amplify-cli e2e still saw a `Policy-Min-TLS-1-0` `CREATE_FAILED` for v1 searchable after #3456 merged. The companion v2 (OpenSearch) fix in #3472 already pairs `enforceHttps: true` with `tlsSecurityPolicy: TLS_1_2`, so only the v1 path was left incomplete. #### Fix Add `EnforceHTTPS: true` to the v1 domain's `DomainEndpointOptions`, matching v2 behavior. The existing unit test (which incorrectly asserted `EnforceHTTPS` was undefined) is updated to assert `true`. ## Testing `jest SearchableModelTransformer`: 7 passed, 7 snapshots passed, `resources.ts` at 100% coverage. Split out from #3494 (PR-5 of the full split).
sarayev
added a commit
that referenced
this pull request
Jun 26, 2026
…prove harness failure logging (#3499) ## Description Two Gen1 e2e harness improvements in `amplify-e2e-core`. #### Ensure Gen1 placeholder app before `amplify init` Adds an idempotent, best-effort run-start step that guarantees the Gen1 deprecation-bypass placeholder app (`DoNotDeleteAppToBypassGen1Deprecation`) and its `test` backend environment exist in each e2e shard's account + region before any `amplify init` runs. This self-heals the Gen1 end-of-life gate: if a prior run's cleanup deleted the placeholder app, the suite would otherwise be blocked. The new `ensureGen1PlaceholderApp(region)` helper uses `@aws-sdk/client-amplify`: it paginates `ListApps`, creates the app via `CreateApp` only when missing, and creates the `test` environment via `CreateBackendEnvironment` only when `ListBackendEnvironments` shows it absent. It defaults region to `process.env.CLI_REGION`, relies on the ambient e2e credentials, and swallows/logs all errors so a healthy run is never broken. It is wired as a Jest `globalSetup` hook in both Gen1 e2e packages (`amplify-e2e-tests` and `graphql-transformers-e2e-tests`) so it runs once per shard, via standalone modules that avoid the heavy e2e-core barrel (and its native `node-pty` dependency). #### Improve harness failure logging `initJSProjectWithProfile` now emits an explicit `initJSProjectWithProfile SUCCESS` / `FAILED: <err>` instead of the misleading unconditional `Result of initJSProjectWithProfile: null` on success. The nspawn `run()` exit handler now dumps the full captured output plus the signal alongside the exit code on a non-zero exit, instead of only the last 10 lines (`lastScreen`) which could be empty for push/add-function failures and hid the real error. Timeout branches and the quiet success path are unchanged. ## Testing `tsc` of `amplify-e2e-core` passes. Logging changes are diagnostic-only with no behavior change. Split out from #3494 (PR-6 of the full split).
sarayev
added a commit
that referenced
this pull request
Jul 9, 2026
…R Public images (#3496) #### Description of changes Bitnami container images were permanently removed from the Amazon ECR Public Gallery (June 10, 2026), so every `public.ecr.aws/bitnami/*` pull now fails with a manifest-not-found error. The customer-facing container templates scaffolded by `amplify add api` (container) all referenced bitnami base images, breaking docker builds for every customer on a cold cache. #### Bitnami → Docker Official Images migration All four container templates under `packages/amplify-category-api/resources/awscloudformation/container-templates/` are migrated to the equivalent Docker Official Images on ECR Public — the long-term alternative recommended in the [AWS ECR-removal blog post](https://aws.amazon.com/blogs/containers/bitnami-image-removal-from-ecr-public/): - `public.ecr.aws/bitnami/node:22` → `public.ecr.aws/docker/library/node:22` - `public.ecr.aws/bitnami/python:3.12-prod` → `public.ecr.aws/docker/library/python:3.12` #### Pre-existing python template regression also fixed PR #3436 introduced `public.ecr.aws/bitnami/python:3.12-prod` — a tag that never existed (bitnami python tags always carry an OS suffix, e.g. `-prod-debian-12`). The python template was already broken with manifest-not-found before the ECR removal. The migration to `public.ecr.aws/docker/library/python:3.12` resolves both issues simultaneously. #### Issue #, if available Split out from #3494 (PR-4 of the full gen1 stabilisation split). Fixes the container-template breakage introduced by the bitnami ECR removal. #### Description of how you validated changes Validated live: `public.ecr.aws/bitnami/node:22` no longer resolves. `docker build` exits 0 on both the node (graphql-express) and python (dockercompose-rest-express) templates against the new `docker/library` base images; `npm install` / `pip install` succeed and containers start cleanly. #### E2E run — batch af555d89 Meets the team's **no-regression + fixes ≥ 1 test** bar. The bitnami fix is confirmed by the absence of manifest-not-found errors in the e2e run. Remaining shard failures are pre-existing and unrelated to this Dockerfile change: | Failure bucket | Root cause | Touches container templates? | |---|---|---| | `function_migration`, `http_migration`, `custom_query_mutation_extension` | Upstream Node-24 `amplify add function` inquirer crash (separate fix in flight) | No | | `sql_pg_models`, `rds_*` | RDS provisioning infra flakes | No | | `AuthV2`, `SubscriptionsRTF` | AppSync API quota in deploy account 740728351410 | No | | `cleanup_e2e_resources` | Benign post-run reaper | No | No regression introduced by this PR. #### Checklist - [x] PR description included - [x] E2E test run linked (batch af555d89) - [x] Tests are changed or added (no-regression + fixes ≥1 test bar met) - [x] Relevant documentation is changed or added (and PR referenced) By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of changes
This branch fixes the live breakage caused by Bitnami images being removed from Amazon ECR Public Gallery, fixes a pre-existing container-template regression that predates the removal, and completes the TLS 1.0 → 1.2 enforcement for the v1 (Elasticsearch) searchable transformer.
Bitnami ECR Public removal — container templates
Bitnami container images were permanently removed from ECR Public on June 10, 2026, so any
public.ecr.aws/bitnami/*pull now fails. All four customer-facing container templates scaffolded by the API category referenced Bitnami base images, which breaksamplify add api(container) docker builds for every customer on a cold cache.Per the AWS guidance, the blog's primary mitigation (mirror to a private ECR repo) is not appropriate here because these templates are generated into each customer's own project — we cannot embed a customer-specific account/registry URI into scaffolding. The blog's recommended long-term path is to move to an equivalent official base image. These templates were migrated to the Docker Official Images mirror published on ECR Public, preserving
node/npm/python/pipbehavior with no customer configuration:public.ecr.aws/bitnami/node:22→public.ecr.aws/docker/library/node:22(3 templates)public.ecr.aws/bitnami/python:3.12-prod→public.ecr.aws/docker/library/python:3.12(1 template)Both a node template (graphql-express) and the python template (dockercompose-rest-express) were validated with real
docker build+docker run: builds exit 0, dependencies install on the new bases, and the containers start cleanly.Container regression introduced by #3436
PR #3436 ("chore: update outdated container template dependencies") changed the python base image from the valid tag
public.ecr.aws/bitnami/python:3.8-prod-debian-10topublic.ecr.aws/bitnami/python:3.12-prod. The bare3.12-prodtag does not exist in the Bitnami python repo — Bitnami-prodpython tags always carry an OS suffix such as-prod-debian-12— so the python template build failed with a manifest-not-found error even before the ECR Public removal. The migration above resolves this regression as well, sincepublic.ecr.aws/docker/library/python:3.12is a valid, existing tag. (#3396 was also reviewed and touches only Node version bumps / CI config — it does not modify any Dockerfile or container template.)TLS 1.2 enforcement on v1 (Elasticsearch) searchable
PR #3456 set
DomainEndpointOptions.TLSSecurityPolicy = 'Policy-Min-TLS-1-2-2019-07'on the v1 Elasticsearch domain but did not setEnforceHTTPS. OnAWS::Elasticsearch::Domain, the minimum TLS policy only governs the HTTPS endpoint, so withoutEnforceHTTPS: truethe policy is not applied and the domain keeps reportingPolicy-Min-TLS-1-0-2019-07— which is why amplify-cli e2e still produced aPolicy-Min-TLS-1-0CREATE_FAILED for v1 searchable after #3456. The companion v2 (OpenSearch) fix in #3472 already pairsenforceHttps: truewithtlsSecurityPolicy: TLS_1_2and is complete; only the v1 path was left incomplete.This branch adds
EnforceHTTPS: trueto the v1 domain'sDomainEndpointOptionsso the TLS 1.2 minimum is actually enforced, matching the v2 behavior. The existing unit test (which incorrectly assertedEnforceHTTPSwasundefined) was updated to assert it is nowtrue.CDK / CloudFormation Parameters Changed
AWS::Elasticsearch::DomainDomainEndpointOptions.EnforceHTTPSset totrueon the v1 searchable domain (paired with the existingTLSSecurityPolicy: Policy-Min-TLS-1-2-2019-07): https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticsearch-domain-domainendpointoptions.htmlIssue #, if available
N/A — addresses the Bitnami ECR Public removal and follow-up to #3456 / #3472.
Description of how you validated changes
graphql-express(node):docker buildexits 0; container logsListening on localhost:3000/graphql.dockercompose-rest-express/python:docker buildexits 0; Flask dev server starts on0.0.0.0:5000.public.ecr.aws/bitnami/node:22no longer resolves (manifest inspect fails) whilepublic.ecr.aws/docker/library/{node:22,python:3.12}resolve.jest SearchableModelTransformeringraphql-elasticsearch-transformer: 7 passed, 7 snapshots passed,resources.tsat 100% coverage. Confirmed the compiledlib/resources.jsemits bothEnforceHTTPS: trueandTLSSecurityPolicy: 'Policy-Min-TLS-1-2-2019-07'.Checklist
yarn testpasses (scoped to the touchedgraphql-elasticsearch-transformerpackage)By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.