When a PR is created/updated in the mbedtls-framework repo, run CI jobs (based on all.sh) against 3.6 and development HEAD associated with the framework as resulting from the PR. Result of the CI is to start with only informative, even if it fails the PR can be merged. It's intended use is to check that when we do not aim to make a backward-compatible change for some (if not all) mbedlts branches, the change is actually backward compatible for those branches.
For backward-incompatible changes we will, to start with at least, rely on the mbedtls CI to validate the changes: CI run of a PR updating the framework submodule pointer to the framework PR head (see "Watershed approach for backward-incompatible framework change" in framework-design.md in PR #4.
Regarding the all.sh components to run, some thoughts:
probably not much value in running sanitizer, test_cmake_xyz components
Add CI support.
When a PR is created/updated in the mbedtls-framework repo, run CI jobs (based on all.sh) against 3.6 and development HEAD associated with the framework as resulting from the PR. Result of the CI is to start with only informative, even if it fails the PR can be merged. It's intended use is to check that when we do not aim to make a backward-compatible change for some (if not all) mbedlts branches, the change is actually backward compatible for those branches.
For backward-incompatible changes we will, to start with at least, rely on the mbedtls CI to validate the changes: CI run of a PR updating the framework submodule pointer to the framework PR head (see "Watershed approach for backward-incompatible framework change" in framework-design.md in PR #4.
Regarding the all.sh components to run, some thoughts: