Skip to content

fix(docker): install cached custom starter on container restart#35789

Open
wezell wants to merge 2 commits into
mainfrom
fix/custom-starter-cached-install
Open

fix(docker): install cached custom starter on container restart#35789
wezell wants to merge 2 commits into
mainfrom
fix/custom-starter-cached-install

Conversation

@wezell
Copy link
Copy Markdown
Member

@wezell wezell commented May 21, 2026

Summary

  • The Docker init script 40-custom-starter-zip.sh only exported DOT_STARTER_DATA_LOAD inside the download branch, so a cached starter zip was never applied on restart.
  • Moved the export to run whenever the cached file exists and is non-empty, so cached starters install on every boot.
  • Quoted path expansions to satisfy shellcheck.

Fixes #35788

Test plan

  • Start container with CUSTOM_STARTER_URL set → fresh download, starter installed.
  • Restart container with cached zip on disk → no re-download, starter still installed (DOT_STARTER_DATA_LOAD exported).
  • Failed/zero-byte download is cleaned up and no starter export occurs.

🤖 Generated with Claude Code

The startup script only exported DOT_STARTER_DATA_LOAD inside the
download branch, so when the starter zip was already cached on disk
the container would log "custom starter already downloaded" and boot
without applying the starter. Move the export to run whenever the
cached file exists and is non-empty, and quote paths to satisfy
shellcheck.

Fixes #35788

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@claude
Copy link
Copy Markdown
Contributor

claude Bot commented May 21, 2026

Claude finished @wezell's task in 50s —— View job


Rollback Safety Analysis

  • Read rollback-unsafe categories reference
  • Reviewed PR diff (433ea3e1...6961919c)
  • Analyzed diff against every unsafe category
  • Applied label

Verdict: ✅ Safe To Rollback

Files changed (1):

  • dotCMS/src/main/docker/original/ROOT/srv/40-custom-starter-zip.sh (Docker init script, +15/-13)

Category review:

Category Match?
C-1 Structural Data Model No — no DB or schema changes
C-2 ES Mapping No — no ES changes
C-3 Content JSON Model Version No — no CURRENT_MODEL_VERSION bump
C-4 DROP TABLE/COLUMN No — no DDL
H-1 One-Way Data Migration No — no data backfill
H-2 RENAME TABLE/COLUMN No
H-3 Primary Key Restructuring No
H-4 New Field Type No
H-5 Binary Storage Provider No — this is the starter-zip download cache (/data/shared/dotcms-starter-*.zip), not FileStorageAPIImpl or StoragePersistenceProvider
H-6 DROP PROCEDURE/FUNCTION No
H-7 NOT NULL column No
M-1 Column Type Change No
M-2 Push Publishing Bundle No
M-3 REST/GraphQL API Contract No
M-4 OSGi Plugin API No

Why it is safe: The change is confined to a container startup shell script that decides whether to set DOT_STARTER_DATA_LOAD based on the presence of a cached starter zip. It does not alter any database schema, Elasticsearch mapping, JSON model version, API contract, or OSGi-exposed interface. Rolling back to the previous container image restores the prior shell-script behavior with no data or runtime consequences — the cached zip on disk remains readable by either version.

Label AI: Safe To Rollback applied.
fix/custom-starter-cached-install

Per review feedback on PR #35789:
- Switch the cache-presence check from -f to -s so a stale zero-byte
  file triggers a re-download instead of silently skipping both the
  download and the DOT_STARTER_DATA_LOAD export.
- Quote the remaining path expansions in the file so the shellcheck
  claim in the PR description holds end-to-end.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI: Safe To Rollback Area : Backend PR changes Java/Maven backend code

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

Custom starter zip not installed when already cached on disk

1 participant