I am running Parse dashboard locally - works fine
Deployed to Heroku (see references below) - it runs but does now load anything (blank screen). No errors in the log - app is up and running.
I have tried to deploy based on the following links:
Stackoverflow
Codementor
The issues came down to the bundles/ directory not being pushed correctly to git (and thus Heroku).
Make sure you run 'npm install' on your local directory
Make sure you add/commit the entire directory to git.
Related
I admit I'm a GoLang newbie. In an attempt to learn Go, I developed an app about a year ago (based on the Heroku Getting started repository) and deployed it to Heroku. I used the heroku local server to develop it locally and deployed it successfully. Now I want to make some changes but I don't have the original source, so I have cloned the app from the Heroku repository.
I have got it running locally with the following steps:
export GOPATH=~/project_path
export GOBIN=$GOPATH/bin
go get
go install
heroku local
So far, so good. The problem is that when I make a simple change to the code in main.go, it doesn't show up in the browser. I've tried running go install and restarting the server after making the change but it makes no difference.
I've noticed that the file name in the Procfile is now incorrect (go-getting-started instead of the name of my project folder) but the server still runs and changing the name doesn't make any difference, locally at least. Same goes for the Dockerfile.
What am I doing wrong please?
Every time you make a change to a Go file in the project you need to run go install and stop and restart the heroku local server.
You might want to just run the server yourself with PORT=5000 go run main.go so that you only have to restart one thing. Or you can check out something like https://github.com/pilu/fresh which will listen to filesystem changes and restart your server for you.
Trying to deploy a Node app and usually have no issues at all. Now I'm having TypeScript resolution errors that only fail on Heroku but work locally and I have no idea how to test it ON Heroku.
I know I can do heroku run bash but then I'm just in an empty directory without my code.
I'd like to heroku run bash after the failed build and look around and run my commands as Heroku would so I can see why I'm having module resolution errors.
Can't find anything about it on Google whatsoever
I want to deploy django app to heroku via codeship and it generate an error and that is wget -O/dev/null http://something.herokuapp.com
How to fix the problem
Marko from the Codeship team here. Could you paste some more log output, or open a ticket on https://helpdesk.codeship.com?
Judging from the command you pasted above, I'd guess the check if the Heroku app, that you just deployed to, is running fails and this causes the build itself to fail.
Without any additional configuration we check the root URL for your application at http://HEROKU_APP_NAME.herokuapp.com via wget and see if it returns an HTTP/2xx or HTTP/3xx status code.
If it does, the check succeeds, else the build fails.
You can take a look at the script we use to perform the check at https://github.com/codeship/scripts/blob/master/utilities/check_url.sh
I'm having trouble deploying my app to Heroku. I don't have this issue with an app I started several months ago so I think it must be something wrong with the lastest Angular Fullstack. After several hours of trouble shooting I decided to start from scratch just to see if AngularFullstack would deploy if you create a completely fresh app in an empty directory.
I created the app in the terminal with:
yo angular-fullstack
Without doing anything else I deployed the app to Heroku by typing this in the terminal:
yo angular-fullstack:heroku
Finally I went to the Heroku webaddress and I get the following "Application Error":
An error occurred in the application and your page could not be served. Please try again in a few moments.
If you are the application owner, check your logs for details.
When I look at the Heroku logs I get the exact same error I was getting in my finished project:
Error: ENOENT, no such file or directory '/app/dist/public/favicon.ico'
I've tried putting this file everywhere in my directory structure. There is no 'dist' in directory structure of the new app. I put this directory in the old app with grunt serve:dist but that doesn't fix the problem of locating favicon.ico even though it is there in the public folder. There is no 'app' directory at the top however and it begins looking all the way in my Mac 'User' path. I think this part of the problem that I don't know how to fix.
Hey guys so I've spend the past few days really digging into Docker and I've learned a ton. I'm getting to the point where I'd like to deploy to a digitalocean droplet but I'm starting to wonder about the strategy of building/deploying an image.
I have a perfect Dev setup where I've created a file volume tied to my app.
docker run -d -p 80:3000 --name pug_web -v $DIR/app:/Development test_web
I'd hate to have to run the app in production out of the /Development folder, where I'm actually building the app. This is a nodejs/express app and I'd love to concat/minify/etc. into a local dist folder ane add that build folder to a new dist ready image.
I guess what I'm asking is, A). can I have different dockerfiles, one for Dev and one for Dist? if not B). can I have if statements in my docker files that would do something like... if ENV == 'dist' add /dist... etc.
I'm struggling to figure out how to move this from a Dev environment locally to a tightened up production ready image without any conditionals.
I do both.
My Dockerfile checks out the code for the application from Git. During development I mount a volume over the top of this folder with the version of the code I'm working on. When I'm ready to deploy to production, I just check into Git and re-build the image.
I also have a script that is executed from the ENTRYPOINT command. The script looks at the environment variable "ENV" and if it is set to "DEV" it will start my development server with debugging turned on, otherwise it will launch the production version of the server.
Alternatively, you can avoid using Docker in development, and instead have a Dockerfile at the root of your repo. You can then use your CI server (in our case Jenkins, but Dockerhub also allows for automated build repositories that can do that for you, if you're a small team or don't have access to a dedicated build server.
Then you can just pull the image and run it on your production box.