Skip to content

Conversation

@bensze01
Copy link
Contributor

@bensze01 bensze01 commented Dec 12, 2025

Description

Run Crypto abi-check in TF-PSA-Crypto PRs.
Running the TLS ABI check doesn't do much, since both HEAD and FETCH_HEAD point to the same commit in a Crypto PR-merge job.

PR checklist

CI runs

@gilles-peskine-arm
Copy link
Contributor

You link to https://ci.trustedfirmware.org/view/Mbed-TLS/job/mbed-tls-tf-psa-crypto-restricted-ci-testing/view/change-requests/job/PR-12-merge/1/ as a CI run, but that doesn't seem to have run the abi-check?

@bensze01
Copy link
Contributor Author

Ah - I didn't update the test branch with my changes that added abi_check.py to TF-PSA-Crypto. One moment.

Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, the problem is that currently, when we run the “Interface stability tests” in TF-PSA-Crypto, it's actually comparing the interface between the current version and the current version? That's a really nasty bug, thanks for spotting it!

I don't understand the fix, however.

Running the TLS ABI check doesn't do much, since both HEAD and FETCH_HEAD
point to the same commit in a Crypto PR-merge job.

Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
@bensze01 bensze01 force-pushed the dev/bensze01/crypto-abi-check branch from 7b89051 to 1d08642 Compare December 16, 2025 12:07
@bensze01
Copy link
Contributor Author

I went ahead and removed all of the file presence detection.

Since this reduced the PR size by a lot, I've squashed the back-and-forth changes.

TARGET_REPO is more generic and better named for what it actually does.
eg. This allows us to run abi_check.py on TF-PSA-Crypto branches without
enabling RUN_TF_PSA_CRYPTO_ALL_SH.

Also plumb TARGET_REPO for run_release_job().

Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
@minosgalanakis minosgalanakis self-requested a review December 16, 2025 14:52
void run_release_job(String tls_branches, String tf_psa_crypto_branches) {
void run_release_job(String target_repo, String tls_branches, String tf_psa_crypto_branches) {
def (tls_split, tf_psa_crypto_split) =
[tls_branches, tf_psa_crypto_branches].collect({branches -> branches.split(',').findAll()})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a blocker but would it make sense to filter out whitespace?

def (tls_split, tf_psa_crypto_split) = [tls_branches, tf_psa_crypto_branches].collect { s -> (s ?: '').split(/\s*,\s*/).findAll { it } }

minosgalanakis
minosgalanakis previously approved these changes Dec 16, 2025
Copy link
Contributor

@minosgalanakis minosgalanakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking closer at it, it depends on the state of all the other prs in the group.

@minosgalanakis minosgalanakis self-requested a review December 16, 2025 17:02
Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is correct, but I want better documentation.

* This script takes the following parameters:
*
* Repos and branches
* - TARGET_REPO
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking it up in https://review.trustedfirmware.org/plugins/gitiles/ci/mbedtls/mbed-tls-job-configs/+/refs/heads/openci-migration/mbed-tls-restricted-pr-test-parametrized.yaml the possible values of TARGET_REPO are tls, tf-psa-crypto and framework. Can we make them consistently the actual repo names, or consistently short versions? Either mbedtls, TF-PSA-Crypto, mbedtls-framework or tls, crypto, framework.

And how do restricted repos fit into this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make them consistently the actual repo names, or consistently short versions? Either mbedtls, TF-PSA-Crypto, mbedtls-framework or tls, crypto, framework.

I'd like to move us to using enums (perhaps in a separate PR), but unfortunately - is not valid in groovy identifiers.

Just to orient myself towards the eventual goal - would you prefer the style RepoType.crypto or RepoType.TF_PSA_CRYPTO?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not something we'll have to type on a daily basis, so I'd prefer to just use the repository name.

I don't really mind if it's a string. We don't really need the whole Groovy code to know about all the possible repositories.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make them consistently the actual repo names, or consistently short versions? Either mbedtls, TF-PSA-Crypto, mbedtls-framework or tls, crypto, framework.

I'd like to move us to using enums (perhaps in a separate PR), but unfortunately - is not valid in groovy identifiers.

Just to orient myself towards the eventual goal - would you prefer the style RepoType.crypto or RepoType.TF_PSA_CRYPTO?

I would advise against enums at this stage with groovy. I agree with Gilles to keep in String format.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And how do restricted repos fit into this?

TEST_BRANCH specifies the "type" of the repo, ie. the value of which variable we use out of MBED_TLS_REPO, TF_PSA_CRYPTO_REPO and FRAMEWORK_REPO.

I've detailed the exact effects it has at the moment in the Jenkinsfiles.

* This script takes the following parameters:
*
* Repos and branches
* - TARGET_REPO
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this is new and currently only available in the mbed-tls-restricted-pr-test-parametrized job, from the openci-migration branch of the job configs which is still the one that the new CI uses.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to push a change to openci-migration anyways to adapt to the new values of TARGET_REPO - I'll just add it to the other parametrized jobs as well instead of documenting this as a limitation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This way we don't need to add the shell script to the TF-PSA-Crypto repo.

Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
The intent is to mimic the behaviour of the three CIs, so don't skip TF-PSA-Crypto
tests if the target is 'framework'.

Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM on code inspection except for a typo.

We'll need to do test runs for all three values of TARGET_REPO, both release and pr-merge, maybe also some test runs in restricted repositories, to make sure that we haven't forgotten a place where a repo name needs to be updated. (Admittedly an enum would give us more confidence there. Note that I'm not against an enum, I just don't think it's in scope here.)

Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Copy link
Contributor

@minosgalanakis minosgalanakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@gilles-peskine-arm gilles-peskine-arm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM on code inspection

@github-project-automation github-project-automation bot moved this from In Development to Has Approval in Roadmap pull requests (new board) Dec 17, 2025
@gilles-peskine-arm gilles-peskine-arm added the approved Approved in review. May need additional CI. label Dec 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Approved in review. May need additional CI. enhancement New feature or request needs: ci priority-high size-xs Estimated task size: extra small (a few hours at most)

Projects

Development

Successfully merging this pull request may close these issues.

4 participants