When deploying my application to CloudControl I suddenly get an unexpected error while pushing the code.
remote: [1G-----> Kohana Framework detected
remote: mkdir: cannot create directory `application/cache': No such file or directory
remote: [1G ! cloudControl push rejected, failed to compile php app
I do not use the typical folder structure of Kohana. I place the system and module folder outside of my application folders. This allows me to keep the application clean and works fine in Kohana.
For example:
-doc_root
-- modules (all modules)
-- system (kohana framework only)
-- app1 (some single application)
--- application
---- classes... (and so on)
--- webroot
---- index.php
Because I am aware of a LoadBalances document root system I do not have any tmp or cache folders inside of my doc_root.
This error seems to be new and makes it kinda impossible for me right now to push and deploy any changes to my application.
Do I really need to change my folder layout? Can the Buildpack (https://github.com/cloudControl/buildpack-php) detect my structure somehow? Can I tell the Buildpack what my structure looks like?
This layout is currently not supported by the buildpack. You can set your document root manually though (in this example AFAICT the webroot would be /app/www/app1/webroot).
Related
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 trying to push Kibana
https://www.elastic.co/products/kibana
to Bluemix PaaS via cloudfoundry. At cf push i get this error
Error uploading application.
GetFileAttributesEx C:\Users\asd\qwe\zxc\installedPlugins\shield\node_modules\eslint\node_modules\file-entry-cache\node_modules\flat-cache\node_modules\del\node_modules\globby\node_modules\glob\node_modules\inflight\node_modules\wrappy\package.json: The system cannot find the path specified.
i can see that the package.json is actually present at that path! How do i resolve this?
cf --version
cf version 6.12.4-b4b6af1-2015-09-18T10:55:12+00:00
The error is due to the file path being too long. Add the node_modules directory to a .cfignore file in the app's root directory and then push again. The node_modules won't be uploaded and will instead be installed as part of the staging process.
See https://github.com/IBM-Bluemix/nodejs-cloudant/blob/master/.cfignore for an example .cfignore.
You could also switch to npm v3 which keeps the node_modules directory flatter, but you still wouldn't normally push it with your app.
I know that there's couple posts like this one, but solution of any of them works for me.
Here is what I receive when I go for git push heroku master:
Please support. Ignoring node_modules is not working.
Docpad app - package.json file is updated according to docpad's manual.
I also have Procfile set up as in the link above.
PS. I have tried to deploy docpad app via openshift, but while Im going with manual from http://docpad.org/docs/deploy/ I receive error at step 5.
The application 'appname' is configured for git reference deployments but the
artifact provided ('https://github.com/myusername/appname#master') is a url.
Please provide a git reference to deploy (branch, tag or commit SHA1) or
configure your app to deploy from binaries with 'rhc configure-app appname
--deployment-type binary'.
If I configure myapp to deployment-type binary it isnt working neither.
The plugin which heroku tries to install returned 404 and the installation fails due to that.
Verify that the plugin is indeed public and not something you have wrote or used locally.
There is no package with this name hosted on the registry you use.
Remove the line with "docpad-plugin-blah": "2" from your package.json file. That line was provided in the docs simply to show you how to install plugins, but there's no such plugin as blah.
"dependencies": {
"docpad": "6"
},
I strongly recommend that you read through the Getting Started on OpenShift to get an overview of the development workflow using Git.
That being said, and if you really meant to use git reference deployments and you know why you are using them, then read through the Managing Deployments section on the developers page of OpenShift and find out how to properly set up git reference deployments. For instance, 'https://github.com/myusername/appname#master' is not a valid git url and therefore it cannot be cloned.
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).
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.