execution contract #2475
execution contract #2475
Conversation
prepared an execution contract draft Signed-off-by: Dan Calavrezo <[email protected]>
dcalavrezo-qorix
requested review from
AlexanderLanin and
MaximilianSoerenPollak
as code owners
|
|
|
The created documentation from the pull request is available at: docu-html |
AlexanderLanin
left a comment
AlexanderLanin
left a comment
There was a problem hiding this comment.
Lots of comments, but this was a great read! Good content IMHO!
| and CI infrastructure. | ||
| Its goal is to ensure **long-term reproducibility (≥10 years)**, **traceability** and | ||
| **practical hermeticity**, despite changes in underlying infrastructure such as | ||
| GitHub-hosted runners. |
There was a problem hiding this comment.
| GitHub-hosted runners. | |
| GitHub-hosted runners. | |
| It builds on [DR-001], which was concerned about the same topics, but was focused on tools only. This adds details where the original description was too fuzzy. |
(not sure about the syntax)
For me it makes all the difference, that this is perfectly aligned, and not something different.
| - Tools affecting build outputs must either be: | ||
| - managed by Bazel, or | ||
| - explicitly injected as Bazel action inputs, or | ||
| - reflected in cache partitioning |
There was a problem hiding this comment.
not sure what you mean here. Theoretically its enough if they are documented as in R2, but of course we want more.
What about "mirrorable"... no idea how to describe it. I'm talking about pypi for example.
| - managed by Bazel, or | ||
| - explicitly injected as Bazel action inputs, or | ||
| - reflected in cache partitioning | ||
| - Reliance on host state must be minimized and documented where unavoidable. |
There was a problem hiding this comment.
This is not the same indentation as above. So "Tools affecting build outputs must either be...documented" is missing?
| Build actions must not depend on **undeclared inputs**. | ||
|
|
||
| In practice: | ||
| - Tools affecting build outputs must either be: |
There was a problem hiding this comment.
Let's explain "Tools affecting build outputs" to be very clear. With example of such tools. And tools that are less relevant.
e.g. I'm currently not sure whether pytest affects build outputs. Are test results build output?
|
|
||
| ## Three-Layer Execution Contract | ||
|
|
||
| ### Layer 1 — Host Platform Contract |
There was a problem hiding this comment.
x86, arm for Macs would also belong to host?!
| - Provide consistent runtime ABI (`glibc`, `libstdc++`) | ||
| - Ensure tool binaries (e.g. rustc) can execute reliably | ||
| - Eliminate “works on my machine” discrepancies | ||
| - Enable local reproduction of CI builds |
There was a problem hiding this comment.
We need to figure out what exactly has to be identical. Or is it this list?
e.g. devcontainer is based on Ubuntu 24. GitHub Runners are based on Ubuntu 24. Is it now enough to ensure the same python version for python scripts?
| --> | ||
|
|
||
|
|
||
| # DR-001-Infra-Extension: S-CORE Build Execution Contract |
| This layer defines **what Bazel controls and guarantees**. | ||
|
|
||
| #### Bazel Versioning | ||
| - Each repository must contain `.bazelversion`. |
There was a problem hiding this comment.
not every repository is using bazel... well, again it depends on which repositories are relevant here.
| ## Minimum Supported Baselines | ||
|
|
||
| ### OS and Runtime Baseline | ||
| - Minimum supported baseline: **Ubuntu 20.04 LTS** (subject to revision) |
There was a problem hiding this comment.
Baseline is defined in layer 2. So layer 3 should not mention an exact version?
| ### Rationale | ||
| We explicitly do **not** support all historical `glibc` or kernel versions. | ||
| Portability is achieved by choosing and documenting a baseline, not by unlimited | ||
| backward compatibility. |
There was a problem hiding this comment.
| backward compatibility. | |
| backward compatibility. Layer 2 can easily be virtualized as needed, for future reproducibility. |
No description provided.