https://www.dropbox.com/s/kegmazybntcdz3p/Screenshot%202020-01-22%2001.32.11.png?dl=0
I put a value for weight, but it still says 'weight' expects a value. This is a brand new Saleor instance on AWS.
Step 12/16 : RUN STATIC_URL=${STATIC_URL} API_URI=${API_URI} APP_MOUNT_URI=${APP_MOUNT_URI} npm run build
---> Running in f8dee4792ae2
> saleor-dashboard@2.0.0 build /app
> webpack -p
Starting type checking service...
Using 1 worker with 2048MB memory limit
ESC[91mKilled
ESC[0mESC[91mnpmESC[0mESC[91m ESC[0mESC[91mERR!ESC[0mESC[91m ESC[0mESC[91mcodeESC[0mESC[91m ELIFECYCLE
ESC[0mESC[91mnpmESC[0mESC[91m ESC[0mESC[91mERR!ESC[0mESC[91m ESC[0mESC[91merrnoESC[0mESC[91m 137
ESC[0mESC[91mnpmESC[0mESC[91m ESC[0mESC[91mERR!ESC[0mESC[91m saleor-dashboard@2.0.0 build: `webpack -p`
ESC[0mESC[91mnpmESC[0mESC[91m ESC[0mESC[91mERR!ESC[0mESC[91m Exit status 137
ESC[0mESC[91mnpmESC[0mESC[91m ESC[0mESC[91mERR!ESC[0mESC[91m
ESC[0mESC[91mnpmESC[0mESC[91m ESC[0mESC[91mERR!ESC[0mESC[91m Failed at the saleor-dashboard@2.0.0 build script.
ESC[0mESC[91mnpmESC[0mESC[91m ESC[0mESC[91mERR!ESC[0mESC[91m This is probably not a problem with npm. There is likely additional logging output above.
ESC[0mESC[91m
ESC[0mESC[91mnpmESC[0mESC[91m ESC[0mESC[91mERR!ESC[0mESC[91m A complete log of this run can be found in:
ESC[0mESC[91mnpmESC[0mESC[91m ESC[0mESC[91mERR!ESC[0mESC[91m /root/.npm/_logs/2020-01-22T11_15_26_755Z-debug.log
ESC[0mThe command '/bin/sh -c STATIC_URL=${STATIC_URL} API_URI=${API_URI} APP_MOUNT_URI=${APP_MOUNT_URI} npm run build' returned a non-zero code: 137
Failed to build Docker image aws_beanstalk/staging-app: g
ESC[0mThe command '/bin/sh -c STATIC_URL=${STATIC_URL} API_URI=${API_URI} APP_MOUNT_URI=${APP_MOUNT_URI} npm run build' returned a non-zero code: 137. Check snapshot logs for details. (Executor::NonZeroExitStatus)
[2020-01-22T11:15:28.365Z] ERROR [3717] : Command CMD-Startup failed!
[2020-01-22T11:15:28.385Z] INFO [3717] : Command processor returning results:
{"status":"FAILURE","api_version":"1.0","results":[{"status":"FAILURE","msg":"(TRUNCATED)...n-zero code: 137\nFailed to build Docker image aws_beanstalk/staging-app: g\n\u001b[0mThe command '/bin/sh -c STATIC_URL=${STATIC_URL} API_URI=${API_URI} APP_MOUNT_URI=${APP_MOUNT_URI} npm run build' returned a non-zero code: 137. Check snapshot logs for details. \nHook /opt/elasticbeanstalk/hooks/appdeploy/pre/03build.sh failed. For more detail, check /var/log/eb-activity.log using console or EB CLI","returncode":137,"events":[{"msg":"Failed to build Docker image aws_beanstalk/staging-app, retrying...","severity":"WARN","timestamp":1579690880},{"msg":"Failed to build Docker image aws_beanstalk/staging-app: g\n\u001b[0mThe command '/bin/sh -c STATIC_URL=${STATIC_URL} API_URI=${API_URI} APP_MOUNT_URI=${APP_MOUNT_URI} npm run build' returned a non-zero code: 137. Check snapshot logs for details.","severity":"ERROR","timestamp":1579691728}]}],"truncated":"true"}
[2020-01-22T13:56:35.276Z] DEBUG [32620] : Reading config file: /etc/elasticbeanstalk/.aws-eb-stack.properties
[2020-01-22T13:56:35.277Z] DEBUG [32620] : Checking if the command processor should execute...
[2020-01-22T13:56:35.280Z] DEBUG [32620] : Checking whether the command is applicable to instance (i-011820325002009fd)..
[2020-01-22T13:56:35.280Z] INFO [32620] : Command is applicable to this instance (i-011820325002009fd)..
Such documentation isn't written yet, and there are a lot of different things you can do. I really love gitlab too! My experience with Saleor's deployment and development tooling in general has been that they provide great starting-point examples for common workflows. I learned a lot working on Saleor. But with the move to the PWA infrastructure during 2.x, lots of the tooling and documentation hasn't been updated yet. Big architectural changes are a ton of work. So right this second we're left figuring it out ourselves.
(To a degree, this has always been true. There's a lot of different ways to deploy and develop, and many overlapping tools to get the job done. It kind of depends on your team, your infrastructure, and how you're using Saleor -- especially true as the stack has gotten more complex.)
Back to your question: High-level, what I'd do is use git submodules for the storefront and dashboard repos, working from the classic Django repo. Then I'd add services using them to the Docker Compose files. Gitlab's more useful for production CI, but Docker Compose can be a part of that too. That's where the conversation gets kinda "well it depends on what you're doing, here are a few ideas".
that right there shows how to add to the Docker Compose files without git submodules, which isn't very useful except to just run the dashboard and storefront without editing them. It's a starting point, though. You can read about git submodules here: https://git-scm.com/book/en/v2/Git-Tools-Submodules
If you use submodules, change the context arg to the dashboard and storefront services to the local directories you're using. Add those directories to the .dockerignore file too so that the celery and web service builds don't start taking forever on those COPY commands
submodules are great. The one drawback is you gotta kinda geek out on git to use them, but once you cross that hurdle they're an excellent tool for figuring out what's compatible with what across the three repositories.
There are a couple other ways to do it, though. You could use separate repos and track which tags or revisions are compatible by using the git repos in the Docker Compose files, but the syntax that targets specific tags or branches or commits.
I personally like the submodule workflow a little better, but it took me awhile to figure out.
\m/ they use them pretty effectively in my other favorite OSS project, SuperCollider
Hi saleor team. In the last days We have seen in your git, that your dash and front repositories don't seem to went at the same speed that your django saleor api back. Have you published in some place the roadmap of saleor or future plans?
We saw these two PR mirumee/saleor#5000
and mirumee/saleor#5043
We were thinking in change from django version to the react storefront version, but we need to make some predictions according to your roadmap.
Thanks!
@rboixaderg Hey Roger! Thank you for your question and support. Our detailed roadmap is still under discussion. I'll keep you updated once it's ready. However, what I can tell is that we're working on a few important features such as multi-currency, CSV import/export, permission groups, multi-channel, and more. There is no exact release date for each function, but you can expect them in Q1 (at least some of them).
The new storefront is still in beta. We fix the bugs and add some small improvements for now. We don't maintain the old storefront anymore, so all the new updates will be available only on the react version. I'll inform you what we are planning to add to the storefront as soon as I know more details.
@/all When it comes to A/B testing, everything boils down to reducing guesswork and making decisions based on hard data. Read more about best practices that should bring results to your e-commerce business: http://bit.ly/ABTesting_article
And what are your best practices for A/B testing? Do you run them often? It would be great if you could share your thoughts with us. We'd love to hear and discuss your experience!
@karolkielecki What would be the recommended setup and configuration to deploy the Saleor Dashboard 2.0? We have the GraphQL API deployed on AWS EBS Docker container. Should Dashboard be in its own separate server or better to have both in the same server or is it better to be deployed on some static host like S3?
PS: I'm more of a developer than devops guy.