Add coverity push script

[paul-elliott-arm]

Description

This is the script to allow us to push coverity builds from Jenkins (or anyone's machine come to that)

Functionality is documented within the script, but to test:

either:

export COVERITY_TOKEN=token
path/to/mbedtls/scripts/push_coverity_scan.py path/to/mbedtls -b origin/coverity_scan -e [email protected]

or

path/to/mbedtls/scripts/push_coverity_scan.py path/to/mbedtls -t token -b origin/coverity_scan -e [email protected]

The token can be found from the coverity web interface, and for the email address I would use your own email address for now (email address is unfortunately compulsary). Conversations are ongoing about which address to use for notifications in the future, the notification email will look like this:

 Your request for analysis of ARMmbed/mbedtls has been completed successfully.
    The results are available at <url>

    Build ID: 607763

    Analysis Summary:
       New defects found: 0
       Defects eliminated: 0

Should new defects be found, another email will be generated, but this will go to the whole team (this is specified within coverity itself)

WARNING - the mbedtls directory specified will be switched to the latest version of the branch specified, any outstanding differences will currently cause the script to fail (in my opinion better than forcing anything).

This constitutes stage 1 of getting coverity push back into CI, getting this script reviewed so that we can at least check its in the correct shape, then stage 2 will be adding the groovy and testing in the repo. I currently envisage this to be added shortly after the existing push from development to coverity_scan branches in the nightly runs.

[paul-elliott-arm]

One possible improvment (although not yet required) would be to parameterise the project so that we can easily use this on other projects, however I'm not sure how many coverity scan projects we are allowed to have!

[gilles-peskine-arm]

I've read the code, but not tried to run it (I'll do that when I re-review). This looks good from a high-level view, but there are several places where I found the code hard to follow. Some places seem to reinvent standard library functions, and some places have difficult-to-understand error handling that looks like it could be simpler. Generally, in Python, prefer context handlers (with …) if possible.

[gilles-peskine-arm]

Thanks for the updates! On code inspection, I believe I now understand what the code is doing, and would be able to maintain it going forward.

I haven't tried running the script yet (and there's a typo that looks like it would fail midway).

I wonder how to test it: how far can we go before consuming a limited Coverity credit: is that consumed by the build request? By triggering? Could we have a test mode in the script that does everything except the credit-consuming step, and leaves behind or prints out all necessary information to do the credit-consuming step manually?

[gilles-peskine-arm]

[non-blocker] It might be better to leave out the list of options here. They're already documented through the argparse calls and I fear that we'll forget to update the text here.

[gilles-peskine-arm]

[non-blocker] Because of the chdir call here, I'm not sure how the each command line arguments will be interpreted if they're relative paths, or if they even can be relative paths. It would be more robust to not call chdir and pass cwd=mbedtls_dir to subprocess.run calls.

[paul-elliott-arm]

I'm really unsure on this one, the scripts themselves generally assume being run from the root MBedTLS dir, so this is how I made it, I haven't noticed any issues up till now.

[paul-elliott-arm]

I wonder how to test it: how far can we go before consuming a limited Coverity credit: is that consumed by the build request? By triggering? Could we have a test mode in the script that does everything except the credit-consuming step, and leaves behind or prints out all necessary information to do the credit-consuming step manually?

I have added -n/--no-upload which will cover this case. Should you use a backup directory for the generated tar file (rather than a temp file) this tar file can then be manually uploaded later, or you can just use this to test the tools download / build steps.

[gilles-peskine-arm]

I ran the script locally with --no-upload and it worked, producing a plausible-looking mbedtls-24-12-06.tar.gz in the --backupdir directory. So this looks good to me both on code reading and on execution apart from possibly the upload step. I'd still like to check that the upload step works for me while you're still partly around, but not today, and in the meantime I can approve this PR already, we can take it from there.