The preferred (some would say required!) design for treating the deployment environment is that the app codebase have no explicit dependencies upon any such environment. That is, no mention of or distinction of behavior based on knowledge that the app is running in ci, next, appdev, prod, etc, nor of the host or host suffix kbase.us.
The codebase does include some instances of reliance on the deployment environment. There really aren't too many instances, and a quick search through the repo resulted in some example links below.
Rather, if there are any differences in behavior based on environment, that should be supplied via a configuration file passed to the docker container when it is launched.
Here is one way to do it, and that worked out for kbase-ui:
- deployment configs are stored in the kbase gitlab instance
- there is one deployment config per supported kbase environment
- upon launching the service/app in a given kbase environment, the deployment tool downloads the configuration file and provides it to the launching container
- the launching container entrypoint is dockerize, which takes a config file and a template, and creates a populated config file available to the app inside the container
- this is in addition to the availability of the standard kbase env variables
This issue is meant to be a start for the conversation and set of changes needed to support this.
Here are some examples:
Here is a dependency on ci.kbase.us in a css file:
https://github.com/kbaseIncubator/dashboard-redesign/blob/0edc0f2eac79467898df18323922bb10091e862f/src/static/kbase_icons.css#L3
A dependency on kbase.us and ci in a react component:
https://github.com/kbaseIncubator/dashboard-redesign/blob/6b7c859f52abfc16844a8b18b89a86d6456a67f4/src/client/components/global_header/Header.tsx#L77
This is an example of an environment url hardcoded in server source:
https://github.com/kbaseIncubator/dashboard-redesign/blob/129539db14c29c364227a9898b033c5ede9adb6b/src/utils/config.py#L26
dependency on kbase.us in a development nginx config:
https://github.com/kbaseIncubator/dashboard-redesign/blob/550e71bbfc1dc09f863f2901516fb73569ab59a4/dev/nginx-default.conf#L25
in a test file config file:
https://github.com/kbaseIncubator/dashboard-redesign/blob/af13a72ba34bb3651f2aff06d5885f10616f6c22/jest.config.js#L60
The preferred (some would say required!) design for treating the deployment environment is that the app codebase have no explicit dependencies upon any such environment. That is, no mention of or distinction of behavior based on knowledge that the app is running in ci, next, appdev, prod, etc, nor of the host or host suffix kbase.us.
The codebase does include some instances of reliance on the deployment environment. There really aren't too many instances, and a quick search through the repo resulted in some example links below.
Rather, if there are any differences in behavior based on environment, that should be supplied via a configuration file passed to the docker container when it is launched.
Here is one way to do it, and that worked out for kbase-ui:
This issue is meant to be a start for the conversation and set of changes needed to support this.
Here are some examples:
Here is a dependency on ci.kbase.us in a css file:
https://github.com/kbaseIncubator/dashboard-redesign/blob/0edc0f2eac79467898df18323922bb10091e862f/src/static/kbase_icons.css#L3
A dependency on kbase.us and ci in a react component:
https://github.com/kbaseIncubator/dashboard-redesign/blob/6b7c859f52abfc16844a8b18b89a86d6456a67f4/src/client/components/global_header/Header.tsx#L77
This is an example of an environment url hardcoded in server source:
https://github.com/kbaseIncubator/dashboard-redesign/blob/129539db14c29c364227a9898b033c5ede9adb6b/src/utils/config.py#L26
dependency on kbase.us in a development nginx config:
https://github.com/kbaseIncubator/dashboard-redesign/blob/550e71bbfc1dc09f863f2901516fb73569ab59a4/dev/nginx-default.conf#L25
in a test file config file:
https://github.com/kbaseIncubator/dashboard-redesign/blob/af13a72ba34bb3651f2aff06d5885f10616f6c22/jest.config.js#L60