Conversation
| app: | ||
| title: Backstage Example App | ||
| baseUrl: http://localhost:3000 | ||
| baseUrl: http://localhost:7000 |
There was a problem hiding this comment.
I think I'm a bit unclear on the role of this file. Will it be used for like e2e tests, or as the default prod setup for forkers (as opposed to create-app users) or what? Just so I'm clear on why the default setup changed to using the backend instead of dockerised frontend, AND removed cors
There was a problem hiding this comment.
(Could perhaps have a comment block at the top of all the config files, including in the skeleton, that describes when and by whom it is used
There was a problem hiding this comment.
Yeah not super clear for me either, since we're suggesting running the backend with NODE_ENV=development in docker 😅 . In general this PR switches the base app-config.yaml to be the production configuration, where the app-config.development.yaml provides overrides for local development.
CORS is moved to local development only, since it's not needed when the app is bundled with the backend.
|
Haha strike that - it was closed but the browser tab had not refreshed :) |
|
I closed #2272 because I could solve my problem differently and wasn't really happy with my changes. But these changes look awesome 🚀 |
3 participants
This makes the
backstage:build-imagecommand be pretty much all you need to get a full deployment up and running. The new--buildoption make the command build all of the input packages before packing them into the workspace, which will be much faster than building all packages. We now also forward all unknown options todocker image build, similar to howbackstage-cli testforwards options tojest.The config is switched around a bit too, moving the development config to
app-config.development.yaml, but the examples still show how to run the image withNODE_ENV=development, since there's a bunch of required config to set otherwise.