Update mbedTLS build process to use ArmClang 6.18

It was confirmed by @Bence Szepkuti in the weekly TF Triage meeting on Nov 12/24, that this is now complete and ticket can be CLOSED.

@Bence Szepkuti : A good reminder that mbedTLS has its own infrastructure distinct in setup from TF-A/TF-M. Which made me thinking - UBL is user-based, i.e. licenses are tied to a particular user(name). License code cannot be reused across different users. I checked mbedTLS builds, and it looks like they run from “ubuntu” user. This is different from TF-A/TF-M. So, a new code is required. And to emphasize it’s separate code and to avoid confusion in the future, let’s have a distinct Jenkins credential id too: MBEDTLS_ARMCLANG_UBL_CODE .

So, I created this credential on https://mbedtls.trustedfirmware.org/, it’s available for use. All other aspects remain the same (like suggestion to use envvar name matching the credential id, etc). Please give it a try a let me know how it works.

I see, thanks for the explanation, @Paul Sokolovskyy!
I ran a test job on the OpenCI, and it looks like the Mbed TLS instance doesn’t have a secret with the ID ARMCLANG_UBL_CODE - could you or someone else on the Linaro side add the secret to the Mbed TLS Jenkins instance as well?

@Bence Szepkuti : Sorry for the delay with reply, we had issues with the UBL license server, so all efforts were on figure that first .

So, here’s how it works:

1. “Activation code”, as needed to request a UBL license, is kept in Jenkins credential storage. For further discussion, it’s ID is “ARMCLANG_UBL_CODE”.

2. So, you don’t need to know the exact code, instead you need to add “credential binding” to a Jenkins job, which will store the code into an environment variable for other code to refer to it. This binding happens in a clean decoupled manner in a Jenkins YAML file for classical jobs, for pipeline jobs, binding is buried in the actual pipeline code.

3. Looking at https://git.trustedfirmware.org/ci/mbedtls/mbed-tls-job-configs/+/refs/heads/master , the mbedTLS jobs use pipeline, so here’s a reference how UBL handling was implemented for TF-M, which also uses pipeline: https://review.trustedfirmware.org/c/ci/tf-m-ci-scripts/+/25249/1/jenkins/build-config.jpl . The call which performs binding is withCredentials(), it takes a code block within which (and only which) the binding will be active. It also takes credential ID and named of the envvar to store value to. I recommend to use the same name to avoid confusion.

4. The command which actually requests UBL license is “armlm activate --code ${ARMCLANG_UBL_CODE}", assuming armlm executable is in PATH (it should be in the same dir as the rest of compiler executables). As you can see, we don’t pass any URL or other params, only the activation code from the envvar. (The default license server is used.)

As the final note, the above patch link was just a first iteration of enabling UBL, it was refactored and elaborated since then: https://git.trustedfirmware.org/ci/tf-m-ci-scripts/+/refs/heads/master/jenkins/build-config.jpl#36 . As can be seen, it just calls a shell script: https://git.trustedfirmware.org/ci/tf-m-ci-scripts/+/refs/heads/master/jenkins/armclang-ubl.sh , and that script has retry login with exponential backoff in case there was an error getting license. I may only recommend doing it like that right away (I generally would recommend to take and reuse this TF-M implementation).

I’ve upgraded our version of armclang on my fork - now I just need the URL and product code that we’re supposed to use for armclang on the OpenCI. Could you send this to me, so I can implement the change? @Paul Sokolovskyy