fix: use ROOT_PASSWORD with default fallback instead of PASSWORD in run.sh

[Copilot]

Removing ENV ROOT_PASSWORD="password" from Dockerfiles (PR #633) left $ROOT_PASSWORD unset at runtime when no -e ROOT_PASSWORD=... is passed. bootstrap/setup.sh and HEALTHCHECK reference $ROOT_PASSWORD directly, causing setup to fail with "You must provide the password of the Root User".

Change

opendj-packages/opendj-docker/run.sh — replace the $PASSWORD intermediate variable with a direct export of $ROOT_PASSWORD:

# Before
export ******
echo "Password set to $PASSWORD"

# After
export ROOT_PASSWORD=${ROOT_PASSWORD:-password}

• $ROOT_PASSWORD is now always set with "password" as fallback, making it available to all child scripts (setup.sh, replicate.sh, HEALTHCHECK) without any further changes
• Removes the unused $PASSWORD variable
• Stops logging the password to stdout

Original prompt

Problem

PR #633 removed ENV ROOT_PASSWORD="password" from the Dockerfiles, but bootstrap/setup.sh and other scripts reference $ROOT_PASSWORD directly. When the container starts without -e ROOT_PASSWORD=..., $ROOT_PASSWORD is empty, causing:

You must provide the password of the Root User.
Unable to connect to the server at "localhost" on port 4444

Root Cause

In opendj-packages/opendj-docker/run.sh, line 45-46 currently read:

export PASSWORD=${ROOT_PASSWORD:-password}
echo "Password set to $PASSWORD"

The fallback value is stored in $PASSWORD, but bootstrap/setup.sh (and HEALTHCHECK) use $ROOT_PASSWORD — which is now empty since the ENV was removed from the Dockerfile.

Required Fix

In opendj-packages/opendj-docker/run.sh, replace these two lines (lines 45-46):

export PASSWORD=${ROOT_PASSWORD:-password}
echo "Password set to $PASSWORD"

with just:

export ROOT_PASSWORD=${ROOT_PASSWORD:-password}

This ensures:

1. $ROOT_PASSWORD is always set with a default fallback of "password" — fixing setup.sh and all other scripts that reference it
2. The unused $PASSWORD variable is removed
3. The password is no longer logged to stdout (security improvement)

No other files need changes — setup.sh, HEALTHCHECK, and all other consumers already use $ROOT_PASSWORD.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: проанализируй почему после измнения тест buid.yml перестал проходить

Assistant: Логи очень длинные и содержат в основном Docker registry debug-логи. Мне нужно увидеть именно ту часть, где тест фактически падает. Давайте посмотрим workflow файл и найдём конкретную ошибку.

Assistant: Now let me look at the run.sh to understand how ROOT_PASSWORD is used at container startup:

Assistant: Now let me look at the actual failing job more closely to understand the specific error:

Assistant: Логи показывают только push-процесс Docker-образов в локальный registry — это нормальное поведение (blob unknown → create → move). Нужно посмотреть на фактическую ошибку шага Docker test, где запускается контейнер. Давайте посмотрим, какие конкретно джобы упали:

Assistant: Let me look at the specific failing step more closely. The logs are from the Docker build/push/test step. Let me check what the actual failure point is.

Assistant: ## Анализ падения build.yml в PR #633

Вывод: Изменения в PR #633 НЕ являются причиной падения теста. Тест build-docker-alpine падает по той же причине, что и на master.

Что изменилось в PR

PR вносит 3 изменения в Dockerfile-ы:

1. Удалён ENV ROOT_PASSWORD="password" — заменён на комментарий
2. HEALTHCHECK изменён: --bindPassword $ROOT_PASSWORD → --bindPassword "${ROOT_PASSWORD:-password}"
3. Добавлены CDDL-заголовки во все файлы

Почему тест НЕ сломан этими изменениями

Посмотрим на run.sh (entrypoint контейнера):

export PASSWORD=${ROOT_PASSWORD:-password}

Скрипт run.sh при setup использует ${ROOT_PASSWORD:-password}, то есть если ROOT_PASSWORD не задан, используется "password". Аналогично, HEALTHCHECK в новом Dockerfile тоже использует ${ROOT_PASSWORD:-password}. Таким образом, поведение контейнера идентично — пароль по умолчанию "password" сохраняется через shell-подстановку.

Реальная причина падения

Сравнивая логи текущего прогона (PR #633) и предыдущего успешного прогона на master (от 2026-04-02), видно абсолютно одинаковую картину — это логи Docker Registry service container, а не ошибки самих тестов:

• "blob unknown to registry" — нормальные сообщения при multi-platform docker push в локальный registry (blob проверяется HEAD, не найден, затем загружается POST/PUT — это стандартное поведение)
• "manifest unknown" — аналогично, манифесты создаются после push всех слоёв

Эти ERROR-уровни в логах registry — штатная работа Docker Registry при push, а не реальные ошибки сборки.

Что реально вызвало conclusion: failure

Workflow run 24241617156 имеет run_attempt: 2 — это был re-run. Наиболее вероятные причины падения:

1. Flaky-тесты в build-maven (матрица из 15 комбинаций Java × OS) — любой таймаут или нестабильный тест в одной из комбинаций роняет весь workflow
2. Инфраструктурные проблемы — wine install, Cassandra/Postgres timeouts, сетевые проблемы при скачивании зависимостей

Рекомендация

Изменения в Dockerfile корректны и не влияют на тесты. Стоит перезапустить (re-run) failed jobs — если они пройдут, это подтвердит, что причина была в нестабильности инфраструктуры, а не в коде PR.

User: протестируй сборку и запуск dockerfile сам

Assistant: К сожалению, я не могу запустить Docker-контейнеры или выполнять команды на сер...

This pull request was created from Copilot chat.