I'm having a weird issue when pushing my app to heroku.
It's an angularjs front app with a basic nodejs server to be able to run it on heroku.
I'm pushing a deployment branch with all the app already "compile" by grunt in a /dist folder
My problem is in the /dist/public directory, I have 4 folders : js, css, img and fonts ; but after a push and checking on the dyno with heroku run bash, only the img one is in /dist/public, the 3 others aren't there.
I try to do a new push, renaming the public folder to another name (ie shared) and this time, all 4 folders are there, so it seems heroku's doing something with folders named public but I can't figure why and how to avoid this suppression/ignoring thing.
Has any of you encountered the same issue, and how to resolve it without having to rename my public folder ?
EDIT :
Adding my .gitignore file for those of you wondering about that:
/.vagrant/machines
/node_modules
/app/bower_components
/.sass-cache
/test
/app/src/lib/config.js
/dist
Do a git add -f dist/public/js dist/public/css dist/public/fonts from within your repo.
You have a .gitignore rule for /dist, which will ignore any files within /dist and its subdirectories, unless they are already being tracked. My guess is, that the files you have newly generated were not being tracked earlier, and hence they were silently ignored.
The -f flag in the git add above will add those forcefully (overriding the ignore rule), and so you will be able to make commits.
If there are only a few files, and you want to avoid adding the whole folders, I would suggest adding each of the individual files forcefully (i.e., with the -f flag).
Related
I am building a web application for an online "build your own" card game. In the application, I have a cards.json file that holds custom card data. This file is changed with fs whenever a user creates a card. Whenever I push local changes, the cards.json file gets overwritten on deploy. That means all the remote data gets lost on every deploy. How can I include a cards.json file remotely but not change the file whenever I push changes using git push heroku master?EDIT: I guess for clarification reasons, I have tried using a .gitignore as well as removing the file from the staging area. I'm not entirely sure, but I think the issue is that when the application is deployed the file is overwritten there.
So I just found out that the data created during runtime will always be deleted/reset.
https://devcenter.heroku.com/articles/dynos#ephemeral-filesystem
I guess the best fixes for anyone else who has this same issue are:
a) Look into Databases and Heroku Add-ons, or
b) This is very workaround, and there might be better ways to do it, but:
// Go into a new directory, and use
$ heroku ps:copy <FILENAME> --app <APPNAME>
// Then, copy+paste the data from this file into your main repo.
/* Now, each time you do this, you need to make sure you delete that file from the
* extra directory you created as ps:copy only works when the file doesnt exist locally.
*/
I think git fetch doesn't work in this instance, as it only pulls that unchanged file, rather than the changed one from the dyno.
Look up the .gitignore file in git, seems to me that's exactly what you're looking for.
If it doesn't recognize .gitignore properly at first:
git add [uncommitted changes you want to keep] && git commit
git rm -r --cached .
git add .
git commit -m "fixed untracked files"
In .gitignore add the cards.json along with the path .
eg. src/test/resources/testdata/cards.json
I am currently using nodejs that is deployed in ebs on aws. I have a function that will write a pdf and then email it off but it says the file path can't be found. I've verified the project file seems to be /var/app/current/, but changing the reference of the file path doesn't seem to remove the error. Any idea how to go about fixing this?
The /var/app/current/ does not exist initially. Its only created at the very last stage of your deployment.
The deployment happens in /var/app/staging/ folder, and at the very last, once everything finishes, /var/app/staging/ is moved into /var/app/current/.
Thus, I would not recommend using absolute paths in your project or config files. Its better to use relative path or container_commands for config scripts:
The specified commands run as the root user, and are processed in alphabetical order by name. Container commands are run from the staging directory, where your source code is extracted prior to being deployed to the application server.
I am having an issue trying to use Capistrano to deploy an application that requires having several Amazon EFS bind mounts inside of the deployment (current) folder.
I have a directory on the webserver in the root called /webroot inside of it is where all of our code currently is along with about 7 folders (bind mounts) that are shared across three nodes.
Inside of my deploy.rb I have the following line set :deploy_to, "/webroot/testingCap" in which Capistrano is deploying the code into the symlinked folder current. This is great but now when it gets to the step of symlinking the bind mount directories for example:/webroot/uploads it throws an error:
rm -rf /webroot/uploads
rm: cannot remove '/webroot/uploads'
Device or resource busy
I am not sure why it is trying to forcefully remove that directory? I thought it was supposed to just symlink to the directory.
My linked_dirs part looks like this inside of deploy.rb:
append :linked_dirs, "/webroot/uploads"
What am I doing wrong?
:linked_dirs only works with relative paths and always uses Capistrano's shared directory.
When you add e.g. "foo" to :linked_dirs, Capistrano will create a symlink within your deployed app. If anything already exists there, it will delete it first (that is why you are seeing the rm -rf).
The destination of that link will always be to the same name in Capistrano's shared directory. So the chain of events will be like this:
rm -rf /webroot/testingCap/current/foo
ln -s /webroot/testingCap/shared/foo /webroot/testingCap/current/foo
Thus if you look inside current, you will a link that points
foo -> /webroot/testingCap/shared/foo
Notice that the path relative to current is identical to the path relative to shared. This is how :linked_dirs works and you can't change it.
For example, if your app expects to store uploads in public/uploads, you will need the exact same relative path to exist inside shared in order for the link to be established. In other words, the link will point like this:
/webroot/testingCap/current/public/uploads -> /webroot/testingCap/shared/public/uploads
In your case, I suspect you can get this to work, but you'll need to make sure that your mount points are located exactly where Capistrano expects them to be.
I run my pages job and it passes, however with the following message at the end
Uploading artifacts...
WARNING: public: no matching files
Uploading artifacts to coordinator... ok
Job succeeded
The website appears not to be served. All the build steps succeeded without error. I tried the build locally on my machine and verified it is correct. The website's entry point is index.html (I guess that's correct?).
How can I troubleshoot this problem? It would be nice if I could do the job "manually" so I could check a few things after the files are built on the CI machine. Like that I don't have to commit+push a new .gitlab-ci.yml all the time for checking / trying things.
Any suggestions are highly appreciated! Thanks!
P.S.: I build the website using Sphinx if that is of importance.
Edit - Some details
I build the documentation via Sphinx' Makefile (which is part of my documentation's source). Sphinx confirms me that the files are placed in build/html (I confirmed this on my local machine) and I copy them to the public folder. Here's the corresponding excerpt of my ci.yaml:
- make html
- mkdir ~/.public
- cp -r build/html/* ~/.public/
- cd
- mv .public public
I don't know what information from Sphinx' conf.py could be interesting for that case, I've scanned through it and it doesn't seem to be corrupted (also the local build works).
As an output I obtain an index.html + several other HTML files which are linked from index.html. This all gets placed in ~/public.
I would really appreciate to be able to do those build steps manually on the build server as I could take a look at the build files then and maybe figure what's wrong. I didn't find any documentation that this was possible however I also don't think that's really the idea behind CI. Right now I'm not sure how I should tackle this problem as it builds fine on my machine and on the other hand I can't access the build server directly.
Edit 2
I verified with
ls -al ~/public
in my ci.yaml file the generated files and they are all at the correct place. Especially:
$ ls -al ~/public
[...]
-rw-r--r--. 1 root root 5621 Apr 13 23:31 index.html
[...]
So it seems that GitLab pages is expecting something else than / something in addition to index.html?? I've run the Jekyll example from the their examples pages repository and this worked fine having an index.html. But maybe Jekyll produces some more files during the build process.
According to this documentation and this tutorial GitLab pages will only consider a folder named public which resides inside the project's directory. That is the HTML content should go to ~/projectname/public instead of ~/public.
I think I got eaten by this problem. Actually ~/public in a docker image, where we are connected as root… is /root/public :) and not what gitlab pages expects.
You should try
mv build/html public
I am running my NodeJS project on DotCloud. Sadly, DotClouds deployment is "project-intrusive" that is it requires a supervisord.conf file to reside in the app-root. My deployment setup looks like this (using git repos).
project-deploy.git/prod/dotcloud.yml
project-deploy.git/prod/project -> project.git
(/prod/project use project.git as a submodule to access the code)
Now, my though of this is that I eventually would end up having different environments like this, e.g. dev, test and stage. The dev environment wouldn't even have a dotcloud.yml file since it is expected to run everything locally.
Well this works pretty well. But the problem is the supervisord.conf file which is just for deployment to dotcloud, now it resides in the project.git repo, but it doesn't belong there since it is just for deployment.
Are there any modules or NodeJS scripts that let you put deployment configuration files elsewhere, and maybe even specify what the target environment is, e.g. node deploy.js --production, or something like that?
There is a way to get rid of supervisord.conf. Assuming that you want to run e.g. node app.js, you can put the following in dotcloud.yml:
www:
type: nodejs
process: node app.js
Now, of course, it doesn't solve the problem of the dotcloud.yml file itself; but at least it reduces clutter a little bit -- removing it from the approot.