Closed galenatjpl closed 1 day ago
Implement a config file-driven approach that feeds the version numbers of marketplace items into the run.sh (and hence cloudformation, bootstrap.go).
By default have a stable.cfg file that has the version numbers of stable components in the marketplace.
stable.cfg
If a --config-file <CONFIG_FILE> argument is specified on the command-line, then those versions in that config file will be used instead.
--config-file <CONFIG_FILE>
The format of the config file would be YAML.
The key in the config file would be the app name in the marketplace. Those that are under: https://github.com/unity-sds/unity-marketplace/tree/main/applications
The value would be the version number (version sub-directory in marketplace under an app).
This would avoid hard-coding versions, for example: https://github.com/unity-sds/unity-management-console/blob/3f75dba50023470af89c3e9d106e009fcf885b11/backend/internal/processes/bootstrap.go#L188C15-L188C22
Each entry in the config file will specify the version that will be installed. If "SKIP" is specified instead of a version number, then that component won't be installed.
This would require logic to control inclusion, for example here: https://github.com/unity-sds/unity-management-console/blob/3f75dba50023470af89c3e9d106e009fcf885b11/backend/internal/processes/bootstrap.go#L60
OPTIONAL: Also, have run.sh (or deploy.sh)print out a table of what components will be installed with what versions?
run.sh
deploy.sh
Implement a config file-driven approach that feeds the version numbers of marketplace items into the run.sh (and hence cloudformation, bootstrap.go).
By default have a
stable.cfgfile that has the version numbers of stable components in the marketplace.If a
--config-file <CONFIG_FILE>argument is specified on the command-line, then those versions in that config file will be used instead.The format of the config file would be YAML.
The key in the config file would be the app name in the marketplace. Those that are under: https://github.com/unity-sds/unity-marketplace/tree/main/applications
The value would be the version number (version sub-directory in marketplace under an app).
This would avoid hard-coding versions, for example: https://github.com/unity-sds/unity-management-console/blob/3f75dba50023470af89c3e9d106e009fcf885b11/backend/internal/processes/bootstrap.go#L188C15-L188C22
Each entry in the config file will specify the version that will be installed. If "SKIP" is specified instead of a version number, then that component won't be installed.
This would require logic to control inclusion, for example here: https://github.com/unity-sds/unity-management-console/blob/3f75dba50023470af89c3e9d106e009fcf885b11/backend/internal/processes/bootstrap.go#L60
OPTIONAL: Also, have
run.sh(ordeploy.sh)print out a table of what components will be installed with what versions?