Add environment value and set config appropriately #201
Conversation
Signed-off-by: Roee Landesman <roee@robustintelligence.com>
Signed-off-by: Roee Landesman <roee@robustintelligence.com>
|
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
|
@ChrisJBurns sorry to tag you in this directly, but wanted to make sure you saw it as its marked stale! Would appreciate a review :) |
There was a problem hiding this comment.
Hi @ri-roee! I agree that this might cause some confusion, sorry if this issue has made you lose some time 😅
I think the main issue is that the "ejected" Dockerfile created when you bootstrap a new Backstage app loads app-config.production.yaml by default. Suggesting to use an app-config.production.yaml file isn't appropriate in case sensitive data is present in the file. This is the reason why this chart provides a few options for passing app-config files: https://github.com/backstage/charts/tree/main/charts/backstage#configure-your-backstage-instance
I think the best way to address the issue is to remove the extra "--config", "app-config.production.yaml" argument in https://github.com/backstage/backstage/blob/c9a2e9663466c6db7d2ed9b036080e6205746268/packages/create-app/templates/default-app/packages/backend/Dockerfile#L52 and perhaps we could mention the docs in this chart describing how to pass extra config files using backstage.args.
| | backstage.containerPorts | Container ports on the Deployment | object | `{"backend":7007}` | | ||
| | backstage.containerSecurityContext | Security settings for a Container. <br /> Ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container | object | `{}` | | ||
| | backstage.environment | Backstage container environment: development, production | string | `"development"` | |
There was a problem hiding this comment.
this adds some complexity as you should be able to achieve the same thing by passing the extra flags you want as arguments:
backstage:
args: ["--config", "app-config.yaml", "--config", "app-config.whatever.yaml"]
|
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
Description of the change
By default the
app-config.production.yamlfile is not used in bootup process of backstage. This leads to misconfiguration and confusion (see attached issue). This PR is a no-op for folks who continue to not setbackstage.environmentvalue, however those using theproductionstring will have the config correctly passed in.Existing or Associated Issue(s)
backstage/backstage#25189
Additional Information
It is not strictly required to pass in
--config app-config.yamlhowever I felt that being extra verbose would be clearer in this case.I noticed that the
ct installtests were failing, even off master, and I believe this is due to the NODE_ENV not being set correctly thus causing the guest auth provider to error out. I now set that env var based on the backstage environmentChecklist
Chart.yamlaccording to semver.values.yamland added to the README.md. The helm-docs utility can be used to generate the necessary content. Usehelm-docs --dry-runto preview the content.ct lintcommand.