Cext 5368/minimal db provisioning

[AjazSumaiya]

Description

Allow a database to be declared in the manifest of an App Builder application and for that database to be automatically provisioned in the specified region when the application is deployed to a specific Project Workspace.

Updated deploy command to provision database if configured

Related Issue

https://jira.corp.adobe.com/browse/CEXT-5368
Related PR- adobe/aio-cli-lib-app-config#43

Motivation and Context

How Has This Been Tested?

linking package locally

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[nofuss]

Some questions and considerations.

[nofuss]

For the moment running db provision in a workspace where a database has already been provisioned (it does nothing), but that might change in the future.

It would be safer to run db status first. If a database is already provisioned nothing more need be done. Also, if a database is already provisioned but in a different region than what is in the manifest, that should be treated at least as a warning.

[AjazSumaiya]

yeah, initially i was doing that but the reason i skipped that the status command check first is that provision command already does status check before provision and logs the details, so running status before provisioning felt kind of repetitive here

[pdohogne-magento]

Since the app:db commands are part of a second plugin, should we verify if it's installed before trying to run the commands? Or is that not a pattern this project follows?

[purplecabbage]

Since the app:db commands are part of a second plugin, should we verify if it's installed before trying to run the commands? Or is that not a pattern this project follows?

Yes, generally the way we have implemented this is that the app command does not call the other command but instead uses the lib.
aio-cli-plugin-app uses aio-lib-runtime to deploy, instead of calling aio-cli-plugin-runtime
and uses aio-cli-lib-console instead of calling aio-cli-plugin-console
The runtime example is a little messy, but the thought is that the libraries have the programatic interface and the cli plugins extend the user interface.

We also need to keep in mind that this release is probably going to come after an alpha|beta of aio-cli-plugin-storage with db commands, so this should not be merged until we are ready to release everything.

[nofuss]

@purplecabbage - I don't understand why you've labelled this a "breaking change". This PR does introduce a new feature, but I am not aware that it is backwards incompatible with the existing feature. Can you explain?

[purplecabbage]

@purplecabbage - I don't understand why you've labelled this a "breaking change". This PR does introduce a new feature, but I am not aware that it is backwards incompatible with the existing feature. Can you explain?
We cannot release this until it is GA, this pr gives it to everyone.