Support deployment_config/working_dir value by TimoSteuerwaldETAS · Pull Request #356 · eclipse-score/lifecycle

TimoSteuerwaldETAS · 2026-07-23T14:39:33Z

This fixes #343 .
Furthermore the config mapping tests have been fixed and are executed on the pipeline.
A feature integration test has been also added which is testing various options, not only working dir.

github-actions · 2026-07-23T14:40:27Z

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.6.0) and connecting to it...
INFO: Invocation ID: 64781860-f88f-483a-8aab-f144a023c9a0
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

Analyzing: target //:license-check (37 packages loaded, 10 targets configured)

Analyzing: target //:license-check (81 packages loaded, 10 targets configured)

Analyzing: target //:license-check (142 packages loaded, 2266 targets configured)

Analyzing: target //:license-check (152 packages loaded, 5310 targets configured)

Analyzing: target //:license-check (163 packages loaded, 6531 targets configured)

Analyzing: target //:license-check (163 packages loaded, 8263 targets configured)

Analyzing: target //:license-check (164 packages loaded, 8271 targets configured)

Analyzing: target //:license-check (164 packages loaded, 8271 targets configured)

Analyzing: target //:license-check (164 packages loaded, 8271 targets configured)

Analyzing: target //:license-check (167 packages loaded, 10159 targets configured)

Analyzing: target //:license-check (168 packages loaded, 10283 targets configured)

INFO: Analyzed target //:license-check (169 packages loaded, 10409 targets configured).
[6 / 15] checking cached actions
[12 / 16] JavaToolchainCompileClasses external/rules_java+/toolchains/platformclasspath_classes; 0s disk-cache, processwrapper-sandbox ... (2 actions running)
[14 / 16] JavaToolchainCompileBootClasspath external/rules_java+/toolchains/platformclasspath.jar; 0s disk-cache, processwrapper-sandbox
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 25.504s, Critical Path: 2.74s
INFO: 16 processes: 12 internal, 3 processwrapper-sandbox, 1 worker.
INFO: Build completed successfully, 16 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

github-actions · 2026-07-23T14:51:13Z

The created documentation from the pull request is available at: docu-html

NicolasFussberger · 2026-07-24T08:08:14Z

+         environment=_docker_configuration["environment"],
+         volumes=_docker_configuration["volumes"],
+         shm_size=_docker_configuration["shm_size"],
+        privileged=_docker_configuration.get("privileged", False),


Any plan to bring these changes to ITF repo?

Something similar is already there. Because today the itf_score version has been increased to 0.5.0, I reverted the patch.

NicolasFussberger · 2026-07-24T08:14:08Z

+    if "initial_run_target" in config or "initial_run_target" in merged_defaults:
+        new_config["initial_run_target"] = config.get(
+            "initial_run_target", merged_defaults.get("initial_run_target")
+        )


I think this change it redundant. There is a validation that ensures that initial_run_target must always be defined (to Startup state)

NicolasFussberger · 2026-07-24T08:17:12Z

-            "working_dir": depl_cfg["working_dir"],
+            # Default the working directory to bin_dir (the directory the
+            # executable lives in) when not set explicitly.
+            "working_dir": depl_cfg.get("working_dir", depl_cfg["bin_dir"]),


This decision to use bin_dir as default exists in two different places, can this be moved to a single function (e.g. get_working_dir)?

NicolasFussberger · 2026-07-24T08:18:30Z

            ],
            "security_policy_details": "policy_name",
            "number_of_restart_attempts": 1,
+            "working_dir": "/tmp",


Could you adapt one of the configs so that we have all cases covered?

Taking the default working dir (as bin dir)

Setting the working_dir in the defaults section

Setting the working dir explicitly on the component (overwriting the default)

NicolasFussberger · 2026-07-24T08:24:23Z

@@ -35,6 +36,8 @@ def run_until_file_deployed(
    :param file_path: path of the file to wait for on the target.
    :param timeout_s: maximum seconds to wait for the file (default: 30).
    :param poll_interval_s: seconds between file-existence checks (default: 0.5).


Maybe update the documentation that poll_interval_s is also used to poll process state

NicolasFussberger · 2026-07-24T08:26:00Z

+                time.sleep(poll_interval_s)
+
+            assert not proc.is_running(), (
+                f"LCM still running {stop_timeout_s}s after SIGTERM"


What happens to other tests when the Process does not shutdown on receiving SIGTERM?
Is the process then killed with -9 to force termination so the next tests are not affected by this?

I have added a kill -9 to not influence other tests.

NicolasFussberger · 2026-07-24T08:27:32Z

+load("//tests/utils/bazel:integration.bzl", "integration_test")
+
+exports_files(
+    ["lm_demo.json"],


I don't understand where is this file and why is it visible for examples folder?

Me neither. Removed.

NicolasFussberger · 2026-07-24T08:36:08Z

+        case SCHED_FIFO:
+            return "SCHED_FIFO";
+        case SCHED_RR:
+            return "SCHED_RR";


I think SCHED_RR was not tested.

NicolasFussberger · 2026-07-24T08:37:24Z

+
+    const uid_t expected_uid = 666;
+    const gid_t expected_gid = 666;
+    const std::array<gid_t, 3> expected_supp_groups = {123, 321, 456};


I think we cover at least the cases:

No supplementary group ids configured

Some supplementary group ids configured

NicolasFussberger · 2026-07-24T08:37:50Z

+    const uid_t expected_uid = 666;
+    const gid_t expected_gid = 666;
+    const std::array<gid_t, 3> expected_supp_groups = {123, 321, 456};
+    const std::string expected_cwd = "/tmp";


I think we should at least cover the cases:

A specific working_dir configured

The default working_dir is used

NicolasFussberger · 2026-07-24T08:38:32Z

+{
+    bool all_pass = true;
+
+    const uid_t expected_uid = 666;


Can this be a reusable process, where you pass the expected values via CLI flags?

Sure. Fixed.

NicolasFussberger · 2026-07-24T08:40:41Z

+    TEST_STEP("Activate RunTarget Startup")
+    {
+        score::cpp::stop_token stop_token;
+        auto result = client.ActivateRunTarget("Startup").Get(stop_token);


Launch Manager goes to Startup by default. I think this is redundant.
Looks like we can remove the whole control_daemon_mock from this test

Think this is actually causing the error in https://github.com/eclipse-score/lifecycle/actions/runs/30273517385/job/90001693926?pr=356#step:4:1286

NicolasFussberger · 2026-07-24T09:30:37Z

+                    "gid": 666,
+                    "supplementary_group_ids": [123, 321, 456],
+                    "scheduling_policy": "SCHED_FIFO",
+                    "scheduling_priority": 10


I think we should also assert some default priority if not configured

Copied smoke test and renamed accordingly.

Allow execution of sched_setscheduler call by adding SYS_NICE capability to the docker environment

Some unit tests are currently broken however.

Before, when working_dir is not set it has been replaced with binary dir in c++ code. As this workaround is now done in python code, there is no need to keep this in c++ code.

With new version 0.5.0 this is no longer needed.

Two test modifications: - If no working_dir is defined, bin directory is used. - A working dir defined on deployment config level can be overridden on component level

if process does not react on SIGTERM

- add another process - parameterize sandbox_options_process.cpp

MaciejKaszynski · 2026-07-28T12:35:04Z

@@ -28,6 +28,7 @@
    script_dir.parent.parent


I think because this file is referenced like this I wonder if the bazel test might not recognise cache misses correctly 🤔. I also don't like storing all of the location of these files as these variables.

I think we can use pytest args and make a custom conftest.py so that the location of this is taken from the args of the pytest command.

I tested this idea out with this patch and the test passes, do you think it would make sense to do it this way?
staged-changes.patch

MaciejKaszynski · 2026-07-28T12:37:22Z

            "bin_dir": depl_cfg["bin_dir"],
-            "working_dir": depl_cfg["working_dir"],
+            # Default the working directory to bin_dir (the directory the
+            # executable lives in) when not set explicitly.


Can you update the user docs to inform of the default value https://eclipse-score.github.io/lifecycle/main/score/launch_manager/docs/user_guide/configuration.html#deployment-config-object

MaciejKaszynski · 2026-07-28T12:39:04Z

+    TEST_STEP("Activate RunTarget Startup")
+    {
+        score::cpp::stop_token stop_token;
+        auto result = client.ActivateRunTarget("Startup").Get(stop_token);


Think this is actually causing the error in https://github.com/eclipse-score/lifecycle/actions/runs/30273517385/job/90001693926?pr=356#step:4:1286

MaciejKaszynski · 2026-07-28T12:43:19Z

+    return pass;
+}
+
+bool verify_sandbox_options()


I think this is a bit long for thet test, can you separate this into another header file like verify_sandbox.hpp

Then would be nice if the API was

::testing::AssertionResult verifySandbox(ExpectedValues)

And the test logic would simply be

EXPECT_TRUE(verifySandbox(ExpectedValues { .uid = xxx, .gid = xxx ... }));

MaciejKaszynski · 2026-07-28T12:47:00Z

+            while proc.is_running() and time.monotonic() < stop_deadline:
+                time.sleep(poll_interval_s)
+
+            if proc.is_running():


I think there is a proc.stop() method that handles the SIGTERM -> SIGKILL escalation. This is also being changed in https://github.com/eclipse-score/lifecycle/pull/328/changes#diff-5a2398a3ecf6f7c0d805b90182ce8c998bee6de87256a9379052fb919e55c202

would it be breaking to not do this change for now, and let the subsequent PR handle that?

MaciejKaszynski · 2026-07-28T12:53:15Z

+// Populate 'out' from the command line arguments. Only the options that are actually present are
+// set; any option left out stays unset and is therefore not verified. Returns false if an
+// unrecognized option is encountered.
+bool parse_arguments(int argc, char** argv, ExpectedValues& out)


Are you sure you want to have the process sandbox configs parsed from args?

Feel like making the ExpectedValue struct hard coded in the test code basically does the same thing, otherwise the values are just hard coded in the json config and you also need logic to parse the args.

github-project-automation Bot added this to LCM - Lifecycle & Health FT Jul 23, 2026

github-project-automation Bot moved this to Backlog in LCM - Lifecycle & Health FT Jul 23, 2026

TimoSteuerwaldETAS requested a deployment to workflow-approval July 23, 2026 14:39 — with GitHub Actions Waiting

TimoSteuerwaldETAS requested a deployment to workflow-approval July 23, 2026 16:51 — with GitHub Actions Waiting

TimoSteuerwaldETAS requested a deployment to workflow-approval July 23, 2026 17:09 — with GitHub Actions Waiting

TimoSteuerwaldETAS mentioned this pull request Jul 23, 2026

[launch_manager] Honor deployment_config.working_dir as the spawned process cwd #343

Open

TimoSteuerwaldETAS marked this pull request as ready for review July 23, 2026 17:12

TimoSteuerwaldETAS requested a deployment to workflow-approval July 24, 2026 06:47 — with GitHub Actions Waiting

NicolasFussberger reviewed Jul 24, 2026

View reviewed changes

TimoSteuerwaldETAS added 3 commits July 24, 2026 11:30

Add stub for test sandbox options

393f902

Copied smoke test and renamed accordingly.

First attempt with opencode

a254a36

Patch the docker environment

6f88fba

Allow execution of sched_setscheduler call by adding SYS_NICE capability to the docker environment

TimoSteuerwaldETAS added 10 commits July 24, 2026 11:30

Update known_limitations.rst

d78fca5

Finish support for setting the working dir

36e549c

Some unit tests are currently broken however.

Stabilize utility function

3ef7843

Fix config mapping tests

875a710

Add config mapping tests to the pipeline

afe9c25

Add check for scheduling priority / policy

84b46af

Remove not needed debug files

5af9455

Tiny modifications and comment

5bed47f

Remove double replacement if working_dir is not set

e74176a

Before, when working_dir is not set it has been replaced with binary dir in c++ code. As this workaround is now done in python code, there is no need to keep this in c++ code.

Fix formatting

04fe95e

NicolasFussberger requested changes Jul 24, 2026

View reviewed changes

Revert no longer needed patch for score_itf

71264de

With new version 0.5.0 this is no longer needed.

TimoSteuerwaldETAS force-pushed the feature/honor-deployment-config-working-dir branch from dad60c7 to 71264de Compare July 24, 2026 09:45

TimoSteuerwaldETAS requested a deployment to workflow-approval July 24, 2026 09:45 — with GitHub Actions Waiting

Test different variations of working_dir presence

ba851bb

Two test modifications: - If no working_dir is defined, bin directory is used. - A working dir defined on deployment config level can be overridden on component level

TimoSteuerwaldETAS requested a deployment to workflow-approval July 24, 2026 13:20 — with GitHub Actions Waiting

TimoSteuerwaldETAS added 4 commits July 24, 2026 15:37

Parameterize sandbox_options_process executable

48a1f65

Remove exports_files, which has been added by fault

c48cf0b

kill with SIGKILL

0af6e77

if process does not react on SIGTERM

Test more scheduling params

fc60ca6

- add another process - parameterize sandbox_options_process.cpp

TimoSteuerwaldETAS requested a deployment to workflow-approval July 27, 2026 10:45 — with GitHub Actions Waiting

Introduce get_working_dir

f49fd5f

TimoSteuerwaldETAS requested a deployment to workflow-approval July 27, 2026 14:07 — with GitHub Actions Waiting

MaciejKaszynski requested changes Jul 28, 2026

View reviewed changes

Comment thread score/launch_manager/src/daemon/src/configuration/config_schema/lm_flatcfg.fbs

MaciejKaszynski requested changes Jul 28, 2026

View reviewed changes

Uh oh!

Conversation

TimoSteuerwaldETAS commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

License Check Results

Uh oh!

github-actions Bot commented Jul 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

TimoSteuerwaldETAS commented Jul 23, 2026 •

edited

Loading

github-actions Bot commented Jul 23, 2026 •

edited

Loading