chore: add non-dev docker-compose workflow #13143
Conversation
There was a problem hiding this comment.
Nice! I wonder if actually replacing the docker-compose.yaml by this, would better meet the user atraction/adoption goal here?
I can imagine new user's always starting the project by docker-compose up
Also beat on the new features almost always triggers tasks that need a webdriver and browser on the worker. So what's the real user gain here?
| db: | ||
| env_file: docker/.env | ||
| image: postgres:10 | ||
| container_name: superset_db |
There was a problem hiding this comment.
can you give these a different name from the dev compose? there's some automation around tests that use these names
| SUPERSET_ENV=production | ||
| SUPERSET_LOAD_EXAMPLES=yes | ||
| CYPRESS_CONFIG=false | ||
| SUPERSET_PORT=8088 |
There was a problem hiding this comment.
better change it to something different from the dev env?
There was a problem hiding this comment.
Do you think there is a use case for running both dev and non-dev at the same time.
There was a problem hiding this comment.
no use case, but I can imagine being used on the wild. It would also make it possible to run both by just a simple change.
But totally optional, feel free to ignore
|
@dpgaspar I would be in favor of making |
|
Awesome! Thanks Tai! |
mistercrunch
added
🏷️ bot
SUMMARY
After some back and forth on #9880, I think it makes sense to provide a docker-compose workflow for non-dev use cases. Waiting for assets to build is a common pain point for users who just want to try out superset and I image we're losing quite a few adopters along the way.
With this new workflow, I was able to get superset up an running in < 1 minute.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
N/A
TEST PLAN
docker-compose -f docker-compose-non-dev.yml upin the base of repolocalhost:8088ADDITIONAL INFORMATION