execution contract

[dcalavrezo-qorix]

No description provided.

[github-actions]

⚠️ Docs-as-Code version mismatch detected
Please check the CI build logs for details and align the documentation version with the Bazel dependency.

[github-actions]

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

[AlexanderLanin]

Lots of comments, but this was a great read! Good content IMHO!

[MaximilianSoerenPollak]

Thanks for the write up, looks over all quite good and a great baseline we can work out the small other stuff.

[FScholPer]

@dcalavrezo-qorix whats the state here?

[FScholPer]

@dcalavrezo-qorix last call for action! I will close it next week if there is no feedback if we now can merge or not

[MaximilianSoerenPollak]

@dcalavrezo-qorix last call for action! I will close it next week if there is no feedback if we now can merge or not

Please do not close it yet.
I have asked for feedback again in the Infra round and Dan is also preparing a PoC.
I would propose to give it until next week, and if then no satisfactory conclusion or at least path forward is reached we take action?

[dcalavrezo-qorix]

Let’s resume the discussion and look at a few remaining gaps around traceability and long-term reproducibility, if that is ok with you.

For ease of discussion I picked persistency as an example, but the same observations likely apply to most S-CORE repositories.

I would like to focus specifically on build reproducibility over a longer time horizon (10+ years).

1. MODULE.bazel.lock is not versioned

We currently do not generate and commit MODULE.bazel.lock.

Even if bazel_dep versions are fixed, dependency resolution can still drift due to:

• transitive selection changes
• registry metadata updates
• yanked releases

Without committing the lock file, we are not freezing the fully resolved module graph. From a reproducibility and auditability standpoint, this seems like a gap.

2. Use of overrides in MODULE.bazel

We still rely on overrides (for ex. git_override).
Even when pinned to a commit SHA, this assumes:

• long-term availability of the upstream repository
• no forced rewrite

For long-term reproducibility, overrides pointing to external GitHub repos may not be sufficient unless we define a mirroring or archival strategy.

3. External toolchain blobs should be mirrored

We fetch external toolchain artifacts (e.g. SDK archives, toolchain tarballs) from vendor URLs.

Even if we verify SHA256, long-term availability of those URLs is not guaranteed.
For true reproducibility, we should clarify whether:

all such artifacts must be mirrored into an S-CORE controlled artifact store, or we accept vendor URLs as a long-term dependency.

This should probably be made explicit in the design decision.

4. Devcontainer image tag is not immutable

The devcontainer currently references an image tag (e.g. v1.1.0).
Container tags can be re-pushed.

If we rely on devcontainer as part of the reproducible developer environment, we may want to:

pin by digest (@sha256:…), or

define a policy that tagged images are immutable and archived.

will add more stuff

[FScholPer]

I think DR would not be enough. We also need some kind of Stakeholder requirements -> tool_Req...