Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add CI support #11

Closed
ronald-cron-arm opened this issue Apr 23, 2024 · 2 comments
Closed

Add CI support #11

ronald-cron-arm opened this issue Apr 23, 2024 · 2 comments
Assignees
Labels
enhancement New feature or request priority-high High priority - will be reviewed soon size-m Estimated task size: medium (~1w)

Comments

@ronald-cron-arm
Copy link
Contributor

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:

  • probably not much value in running sanitizer, test_cmake_xyz components
@ronald-cron-arm ronald-cron-arm added enhancement New feature or request size-m Estimated task size: medium (~1w) priority-high High priority - will be reviewed soon labels Apr 23, 2024
@mpg
Copy link
Contributor

mpg commented Oct 17, 2024

Note: this task implements the following point of the framework CI specification:

CI in the framework repository should run a subset of the CI of all consuming branches, to warn about unintended breakage. This way, most of the time, updating the framework submodule in a consuming branch to the tip of the main branch should work. Gatekeepers can bypass this check if the incompatibility is deliberate.

@mpg
Copy link
Contributor

mpg commented Nov 6, 2024

Closing this as resolved by Mbed-TLS/mbedtls-test#170

@mpg mpg closed this as completed Nov 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority-high High priority - will be reviewed soon size-m Estimated task size: medium (~1w)
Projects
Status: Framework 1/3 (MVP repo split)
Development

No branches or pull requests

3 participants