[scout] update default server configs to use dockerized package registry#255484
Draft
dmlemeshko wants to merge 4 commits intoelastic:mainfrom
Draft
[scout] update default server configs to use dockerized package registry#255484dmlemeshko wants to merge 4 commits intoelastic:mainfrom
dmlemeshko wants to merge 4 commits intoelastic:mainfrom
Conversation
Contributor
|
🤖 Jobs for this PR can be triggered through checkboxes. 🚧
ℹ️ To trigger the CI, please tick the checkbox below 👇
|
dmlemeshko
changed the title
dmlemeshko
force-pushed
the
scout/erp-container-integration
branch
from
fd96162 to
080ad16
Compare
Contributor
Scout Test ReviewNo issues found ✅ All changed files under Share feedback in the #appex-qa channel. Posted via Macroscope — Scout Test Review |
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
| @@ -46,6 +47,8 @@ export async function startServers(log: ToolingLog, options: StartServerOptions) | |||
|
|
|||
| await ensureDefaultSpaceNPRE(config, log); | |||
Contributor
There was a problem hiding this comment.
🟠 High servers/start_servers.ts:48
If any code between startDockerServers (line 50) and procs.waitForAllToStop (line 80) throws an exception, shutdownDockerServers() at line 81 never runs and Docker containers are left running. Move shutdownDockerServers into a finally block or wrap the intervening code in try/finally so cleanup executes regardless of errors.
Also found in 1 other location(s)
src/platform/packages/shared/kbn-scout/src/servers/run_docker_servers.ts:170
If
pullImage,runContainer, orwaitForReadythrows an exception for any server after previous containers have already been started, those containers will be orphaned. TherunningContainersarray accumulates started containers, but if an error occurs mid-loop, the function throws before returning the shutdown function, leaving earlier containers running with no way to clean them up. For example, if servers A and B are enabled, A starts successfully and is pushed torunningContainers, but B fails duringrunContainer(e.g., port conflict as handled on line 61-65), container A is never stopped.
🤖 Copy this AI Prompt to have your agent fix this:
In file src/platform/packages/shared/kbn-scout/src/servers/start_servers.ts around line 48:
If any code between `startDockerServers` (line 50) and `procs.waitForAllToStop` (line 80) throws an exception, `shutdownDockerServers()` at line 81 never runs and Docker containers are left running. Move `shutdownDockerServers` into a `finally` block or wrap the intervening code in `try`/`finally` so cleanup executes regardless of errors.
Evidence trail:
src/platform/packages/shared/kbn-scout/src/servers/start_servers.ts lines 50-82 at REVIEWED_COMMIT. The `shutdownDockerServers` function is obtained at line 50, various operations that could throw are executed at lines 52-76 (runKibanaServer, silence, preCreateSecurityIndexesViaSamlAuth), and `shutdownDockerServers()` is only called at line 81. There is no try/finally block ensuring cleanup runs on exception.
Also found in 1 other location(s):
- src/platform/packages/shared/kbn-scout/src/servers/run_docker_servers.ts:170 -- If `pullImage`, `runContainer`, or `waitForReady` throws an exception for any server after previous containers have already been started, those containers will be orphaned. The `runningContainers` array accumulates started containers, but if an error occurs mid-loop, the function throws before returning the shutdown function, leaving earlier containers running with no way to clean them up. For example, if servers A and B are enabled, A starts successfully and is pushed to `runningContainers`, but B fails during `runContainer` (e.g., port conflict as handled on line 61-65), container A is never stopped.
Contributor
⏳ Build in-progress, with failures
Failed CI Steps
Test Failures
History
|
Contributor
💔 Build Failed
Failed CI Steps
Test Failures
Metrics [docs]
History |
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
3 participants
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.
Summary
Migrates Scout default configs to use the centralized Fleet dockerized package registry from @kbn/test (introduced in #250040), adds Docker container lifecycle management to Scout's server startup flow, and wires --xpack.fleet.registryUrl to Kibana when the registry is enabled.
Changes
packageRegistryDockerfrom@kbn/testin both stateful and serverless base configs, replacing duplicated inline configuration. Scout overrides onlywaitForLogLineTimeoutMs(6 min vs 4 min default) for CI stability.--xpack.fleet.registryUrltokbnTestServer.serverArgswhen FLEET_PACKAGE_REGISTRY_PORT is set, matching the FTR pattern. Custom Scout configs can override this via the standard spread pattern.run_docker_servers.ts) -- a lightweight, standalone async function that pulls images, starts containers, waits for readiness, and returns a shutdown callback. No coupling to FTR's Lifecycle/Rx machinery.run_tests.tsandstart_servers.ts(after ES, before Kibana) so the registry is available at Kibana boot.package_registry_config.ymlfrom Scout config directories (now bundled with @kbn/test).