Adding a new ready condition FileState

[MaciejKaszynski]

Adding a new ready condition for file state.

E.g. a component like "setup network" can wait for some /dev/<network file> to make the component active. Then Later components can depend on this.

[github-actions]

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: 6e777b83-da07-4090-a6ea-3a84cbc1d43e
Computing main repo mapping: 
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: 
Loading: 0 packages loaded
    currently loading: 
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 (35 packages loaded, 10 targets configured)

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

Analyzing: target //:license-check (138 packages loaded, 568 targets configured)

Analyzing: target //:license-check (159 packages loaded, 4640 targets configured)

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

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

Analyzing: target //:license-check (169 packages loaded, 6334 targets configured)

Analyzing: target //:license-check (173 packages loaded, 9568 targets configured)

Analyzing: target //:license-check (176 packages loaded, 11463 targets configured)

Analyzing: target //:license-check (177 packages loaded, 11584 targets configured)

INFO: Analyzed target //:license-check (177 packages loaded, 11589 targets configured).
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: 26.199s, Critical Path: 0.40s
INFO: 16 processes: 4 disk cache hit, 12 internal.
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]

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

[SimonKozik]

JSON schema looks good

[NicolasFussberger]

Suggested change

	process_state:ProcessState = null; // optional
	process_state:ProcessState; // optional

optional non-scalar values are currently all defined without "= null" in this schema because flatbuffer will just return nullptr if not configured which can be used for checking.

Its a bit counter intuitive, but the "= null" is used here for required scalar values so that it can be verified in the code that they have been configured (if they are just marked as required, then flatbuffer will return a default value and its not detectable if they have actually been configured or not).

[NicolasFussberger]

I assume convertReadyCondition should always return a ReturnCondition unless there is an error.
All the other functions use score::cpp::expected return value for this pattern. So I wonder if we shall stick to this pattern here

[MaciejKaszynski]

Well we allow for not configuring a ReadyCondition and default to ProcessState::Running, currently this is defaulted in the ConfigAdapter. Should config handle default values? I think the <config type>loaders isn't a good place as this is specific to the fbs config.

1. Fbs default - only applies to Fbs configs, if we change to others we would have to remember what is defaulted where.
2. Python script - Not sure if adding more code here also makes sense, think we should reduce this file as much as possible.
3. Code
   1. Config/FbsLoader - only applies to Fbs configs
   2. Config additional wrapper - would need to add wrapper.
   3. Component? Would allow for default values for a specific component type, might be useful.

I think we should define this somehow.

[NicolasFussberger]

There is already secondsToMs helper method which has some additional safeguards e.g. to make sure that it does not round down to 0ms

[NicolasFussberger]

All the other methods use score::cpp::expected to return the converted value.

[NicolasFussberger]

Name and description of the test suggest that the dependency is silently ignored, though this case actually crashes the process.

Using the assert is probably a good idea, as silently dropping the dependency would lead to the component being started under unexpected circumstances.