CI: add build and push models workflow

[jordimassaguerpla]

Hi! This is the result of my SUSE Hackweek Project https://hackweek.opensuse.org/23/projects/package-monai-machine-learning-models-for-medical-applications . The motivation was totally personal, to learn more about the Medical Machine Learning Topic, even though has nothing to do with my daily work.

I thought it could be nice to share with you. Might be you can reuse some ideas or details .... or maybe not . Whatever makes sense for your team and your current roadmap.

This is the implementation of a workflow that will build and push into the ghcr.io the example MAP in examples/apps/simple_imaging_app.

This workflow will use terraform to launch a VM with a GPU and then run the monai-deploy-sdk package subcommand inside it.

NOTE: you need to setup the secrets:

• AZURE_CLIENT_ID
• AZURE_SUBSCRIPTION_ID
• AZURE_TENANT_ID
• AZURE_CLIENT_SECRET

The workflow will patch holoscan, so that it works when there is no cache.

The workflow will install a "patched" libseccomp package so that we can install libnvidia-container.

The workflow will use nvidia docker runtime to build, load, export, ... the image.

The workflow uses the smallest/cheapest Azure Image with GPU available in Western Europe, which is Standard_NC4as_T4_v3. For this to work, you might need to request a quota increase to Azure Help Desk.

The default 30GB disc is not enough for the build, so you need to setup a 64GB one.

:WARNING: This will incur in costs in Azure Cloud, use it with caution. It costed me 1.6€ each run.

[jordimassaguerpla]

This https://github.com/Project-MONAI/monai-deploy-app-sdk/pull/474/commits/6013c5e3876ebbcbe8f1816b7ae848b39a58698f adds SBOM (Software Bill Of Materials) and image signing, by using trivy and cosign.

This can later be used to verify the image and check for known vulnerabilities, in order to secure your supply chain.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[MMelQin]

Thank you so much @jordimassaguerpla for this PR. Sorry for this late reply due to the RSNA 2023 prep and others.

MD App SDK proper does not intend to maintain a MAP registry, and the couple container image examples are for demonstration purpose so that adopters of MD App SDK can quickly enhance and make use of the example for their use case. GitHub CR also has certain I/O limits I believe, so pushing (and overwriting) the image over and over may not be helpful.

Having said that, I definitely can see the workflow be used for on-demand (or periodical) publishing task, and the adopters can benefit from this example too!

[jordimassaguerpla]

Thank you so much @jordimassaguerpla for this PR. Sorry for this late reply due to the RSNA 2023 prep and others.

MD App SDK proper does not intend to maintain a MAP registry, and the couple container image examples are for demonstration purpose so that adopters of MD App SDK can quickly enhance and make use of the example for their use case. GitHub CR also has certain I/O limits I believe, so pushing (and overwriting) the image over and over may not be helpful.

Having said that, I definitely can see the workflow be used for on-demand (or periodical) publishing task, and the adopters can benefit from this example too!

I was thinking that could be used as an example for other projects. I agree on every commit makes no sense to update the container. I was more thinking on each new tag and/or on-demand.

Will it make more sense to push this to some example folder or documentation?

Thanks for your answer, no problem it took you a while, perfectly understandable. Congrats on this great project!