ITF integration

[MaciejKaszynski]

This adds a framework to run component tests on a QEMU target using ITF

• Makes native test explicit to invoke by using --config=host .
• Currently copied and pasted the QEMU image definition from reference integration however this should be moved using os_images if that becomes the standard.

Note: This PR creates interfaces that looks like what the new ITF will be with changes from eclipse-score/itf#46 So it should be easy to replace when ITFs refactor is stable.

[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.4.2) and connecting to it...
INFO: Invocation ID: 73eebd65-8b98-40fb-91cc-9f605b75beb7
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
WARNING: For repository 'rules_python', the root module requires module version rules_python@1.8.3, but got rules_python@1.8.5 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'rules_cc', the root module requires module version rules_cc@0.2.16, but got rules_cc@0.2.17 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'score_tooling', the root module requires module version score_tooling@1.1.0, but got score_tooling@1.1.2 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'score_rust_policies', the root module requires module version score_rust_policies@0.0.3, but got score_rust_policies@0.0.5 in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
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 (45 packages loaded, 10 targets configured)

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

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

Analyzing: target //:license-check (150 packages loaded, 4814 targets configured)

Analyzing: target //:license-check (155 packages loaded, 5249 targets configured)

Analyzing: target //:license-check (160 packages loaded, 5298 targets configured)

Analyzing: target //:license-check (166 packages loaded, 9903 targets configured)

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

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

INFO: Analyzed target //:license-check (168 packages loaded, 10037 targets configured).
[14 / 16] [Prepa] JavaToolchainCompileBootClasspath external/rules_java+/toolchains/platformclasspath.jar
[15 / 16] Building license.check.license_check.jar (); 0s disk-cache, multiplex-worker
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: 24.962s, Critical Path: 2.58s
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]

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

[pawelrutkaq]

would not mix test what shall be imho UT with integration tests. Also for linux, itf can simply use Docker as in reference integration.

[pawelrutkaq]

I would ask @ltekieli and @PiotrKorkus to have a look. Nevethless I think we shall push forward os_images to here only use an image from there and setup startup script/small build addons, and not need to copy-paste boilerplate scripts.

[PiotrKorkus]

Nevethless I think we shall push forward os_images to here only use an image from there and setup startup script/small build addons, and not need to copy-paste boilerplate scripts.

I agree. For now I would either put those tests in reference_integration repo or use os_iamges here. Otherwise we will introduce a lot of unnecessary files which should be dependencies not a part of lifecycle.

[MaciejKaszynski]

Nevethless I think we shall push forward os_images to here only use an image from there and setup startup script/small build addons, and not need to copy-paste boilerplate scripts.

I agree. For now I would either put those tests in reference_integration repo or use os_iamges here. Otherwise we will introduce a lot of unnecessary files which should be dependencies not a part of lifecycle.

Yep the end goal is to use the os_images in the end, this is why I made the test target easily changeable by just changing the target in https://github.com/eclipse-score/lifecycle/pull/75/changes#diff-c7986b2ae7b8b3c16507ee583c9a8cfaeff6e886bfb138be0a654b22d721191dR26 but this will be used until the os images has the qnx.

(there is a PR going on right nowhttps://github.com/eclipse-score/os_images/pull/5 however there are issues with the qnx SDP and we need some action from qnx team https://sdvworkinggroup.slack.com/archives/C0AEB5M5FUN/p1772461625738719)

[NicolasFussberger]

@MaciejKaszynski @PiotrKorkus Are os_images already usable now?
I don't think it makes sense to move our own tests into reference_integration repo. It will be too much overhead to work across these two repos.

In case os_images are usable (maybe even only for one OS) I agree we switch to that. Otherwise I would propose we go ahead with the PR and remove the qemu files as soon as os_images is ready.

[NicolasFussberger]

Lifecycle Meeting 25.03.2026:
We decided to remove the qnx support as of now and go ahead with merging the PR.
We add back the qnx support using os_images once ready.

[MaciejKaszynski]

Lifecycle Meeting 25.03.2026: We decided to remove the qnx support as of now and go ahead with merging the PR. We add back the qnx support using os_images once ready.

Qnx removed, docker is working now