Add ability to inject settings as CLI flag while creating a sandbox

Would be great for automation to have an ability to override default metadata with altered metadata (ex. OCAPI settings). Proposal is to add new flag to below command:

sandbox:create --sandbox-metadata path_to_metadata.json

As example using SwaggerUI I can change some settings now but not via CLI tool. This adds additional complexity to automation scripts.

This is what I want to inject (to get last login date in future for monitoring purposes): { "_v": "18.1", "clients": [ { "client_id": "my_client_id", "resources": [ { "methods": [ "get", "post", "put", "patch", "delete" ], "read_attributes": "(**)", "write_attributes": "", "resource_id": "/**" }, { "methods": [ "get" ], "read_attributes": "(**)", "write_attributes": "(**)", "resource_id": "/users/this" } ] } ] }

[tobiaslohr]

Suggestion:

sfcc-ci sandbox:create --realm zzzz --ocapi-settings <ocapi-settings-as-json> --webdav-settings <webdav-settings-as-json> 

• --ocapi-settings <ocapi-settings-as-json> optional, allows to pass OCAPI settings as JSON string
• --webdav-settings <webdav-settings-as-json> optional, allows to pass WebDAV client permissions as JSON string

Note: Both settings amend the settings passed to the sandbox for the API client used by the CLI, they will NOT replace them them. This allows that the CLI is still able to control the sandbox. JSON validation is done syntactically. There is only a basic semantical check done, that ensures, the settings don’t include the same API key as used by the CLI. There is no schema check being done to the JSON. A syntactically proper JSON, but semantically improper JSON may lead to an issue with the sandbox after creation.

Feedback?

[astound-ci]

Great news, we’ll try to make sure JSON string is correct on our end.