request: single file which lists included tools

[AlexanderLanin]

Currently we have at least two:

• https://github.com/eclipse-score/devcontainer/blob/main/src/s-core-devcontainer/.devcontainer/s-core-local/versions.yaml
• https://github.com/eclipse-score/devcontainer/blob/main/src/s-core-devcontainer/.devcontainer/bazel-feature/versions.yaml

This makes total sense from an architecture point of view, but having a single list would be easier for other use cases like non-devcontainer-users, safety analysis, sbom, etc.

[lurtz]

Does it make sense to generate one, which is the merger of both and can be used by downstream users? IMHO that is easiest to implement.

Alternatively the versions.yaml of the S-CORE feature could define all versions, but then it becomes less obvious which feature uses which version definition.

[AlexanderLanin]

@lurtz maybe the question is whether the feature approach is still the best choice? Respective the two separate features?

[lurtz]

@AlexanderLanin it used to be one S-CORE feature, which was dominated by Bazel. Thus I extracted all Bazel tooling into the Bazel feature. I was afraid the S-CORE feature keeps getting growing and growing.

I agree that the features might be overkill. They should be reusable by other teams. At least this allows me to easily comment them out for faster build + test iterations, when I do not need them for developing a specific devcontainer change.

Did you also consider these lockfiles?

• https://github.com/eclipse-score/devcontainer/blob/main/src/s-core-devcontainer/.devcontainer/devcontainer-lock.json
• https://github.com/eclipse-score/devcontainer/blob/main/.devcontainer/devcontainer-lock.json

[AlexanderLanin]

That makes 4 files 😆

We should definitely somehow/somewhere assemble all of them into one.
yaml/json would be nice for easy parsing... but instead of yet another custom format we should assemble them into an sbom file?!
-> custom-tool-installations.sbom

[FScholPer]

stale

[AlexanderLanin]

we need the list. its not stale, its open