Using flatbuffer rules from baselibs

[MaciejKaszynski]

Fixes #154

[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: 239dba34-bb1f-46ba-bb3f-c747e211430b
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 (33 packages loaded, 10 targets configured)

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

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

Analyzing: target //:license-check (135 packages loaded, 985 targets configured)

Analyzing: target //:license-check (145 packages loaded, 4894 targets configured)

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

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

Analyzing: target //:license-check (161 packages loaded, 10134 targets configured)

Analyzing: target //:license-check (162 packages loaded, 10142 targets configured)

Analyzing: target //:license-check (162 packages loaded, 10142 targets configured)

INFO: Analyzed target //:license-check (163 packages loaded, 10268 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: 23.641s, Critical Path: 2.43s
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

[NicolasFussberger]

Do we need both filegroup with public visibility and export_files?

[NicolasFussberger]

Is this file only moved? It appears as new file and no other file removed.

[NicolasFussberger]

This now requires the user to know exactly the generated files which was not required before.

Snippet from the reference integration, to make the changes work:

launch_manager_config(
    name = "lifecycle_configs",
    config = "//showcases/simple_lifecycle/configs:launch_manager_config.json",
)

score_pkg_bundle(
    name = "simple_lifecycle",
    bins = [
        "@score_lifecycle_health//score/launch_manager:launch_manager",
        "@score_lifecycle_health//examples/cpp_supervised_app",
        "@score_lifecycle_health//examples/rust_supervised_app",
        "@score_lifecycle_health//examples/control_application:control_daemon",
        ":lifecycle_signal.sh",
    ],
    config_data = [
        "//showcases/simple_lifecycle:simple_lifecycle.score.json",
    ],
    custom_layout = {
        # Old
        #":lifecycle_configs": "etc/",
        # New
        ":lifecycle_configs_lm_bin": "etc/lm_demo.bin",
        ":lifecycle_configs_hm_bin": "etc/hm_demo.bin",
        ":lifecycle_configs_hmcore_bin": "etc/hmcore.bin",
    },
)

I wonder if we can avoid this, as the config files and number of config files are undergoing changes and this would break the user every time.

[MaciejKaszynski]

Not sure what you mean, previously the bazel rule returned the file group pointing to the etc directory with all the configs. The change makes it so that the bazel macro returns the file group with all the generated files so for the end use the only difference is that we don't hard code the etc directory for them. You can see what needs to be adapted in the integration tests.
I guess we can probably group them again with the etc dir if we don't want to break backwards compat?

[MaciejKaszynski]

oh wait I read the definition of that macro and I see what you mean. I'll change it so that it bundles as I guess in the end we will have one config file