Setup CI/CD Process

[arank]

Build a v1 of CI/CD to do standard sanity checks around deployments/access to read APIs across clouds with Archera Test accounts that we can provide. Starting with AWS & then Azure

Also we need the option for a non-dry run where we can call, with small $ limits, an integration test that requires purchasing / exchanging commitments

[cristim]

@rocketri regarding this setup we will need a set of AWS/Azure/GCP credentials for the account to deploy into.

I will provide a list of permissions for each cloud provider.

[rocketri]

@cristim Please provide list of permissions for each cloud provider. Still waiting on this from you. Thanks!

[cristim]

@rocketri I created terraform code that creates the required permissions for all the 3 cloud providers, which also includes support for Github authorization so we allow the CI/CD pipelines created as github actions on the LeanerCloud/CUDly repo to deploy CUDly to each of the cloud provider accounts where we deploy these permissions.

I committed them to git in the feat/multicloud-web-frontend branch under the below paths:

• AWS: terraform/environments/aws/ci-cd-permissions/
• Azure: terraform/environments/azure/ci-cd-permissions/
• GCP: terraform/environments/gcp/ci-cd-permissions/

Similar to how we do the infrastructure of CUDly itself, each of them have terraform.tfvars.example and backend.hcl.example files that can be used to configure them for the given AWS/Azure/GCP accounts.

I tested each of these for creation/deletion of the CUDly infrastructure within my own AWS, Azure and GCP accounts, and now working on wiring my accounts to the Github Actions so every commit to this branch is deployed to my accounts across all cloud providers.

You can use those to also set the permissions to your own accounts and when the pipeline works I can then update the popeline to point to your accounts.

[cristim]

To give an update on this, we decided to keep the CI/CD Github Actions point to my personal AWS/Azure/GCP accounts, and not use Archera infrastructure for any of these test deployments because the admin-line permissions to create the software may trigger questions from your auditors.

Instead, we just use Archera accounts as target accounts to my own CUDly installation, with limited IAM permissions.

Currently working on the self service account registration and adding multiple target accounts for comprehensive testing.

[cristim]

This was implemented a few weeks ago, and automatically deploying code after every commit across all 3 major cloud providers.