We have been using RequireJS Optimizer in our deployment file for months now. Everything was working.
Basically what we are doing is the following:
We compile our Coffee scripts files
node %DEPLOYMENT_SOURCE%\build\node_modules\coffee-script\bin\coffee -co "%DEPLOYMENT_SOURCE%\src\Web\Scripts" "%DEPLOYMENT_SOURCE%\src\Web\Coffee"
Then we opitmize the js files into a single file using RequireJS:
node "%DEPLOYMENT_SOURCE%\build\node_modules\requirejs\bin\r.js" -o "%DEPLOYMENT_SOURCE%\build\build.js"
Locally, it works #1. But on Azure we have this error:
Cannot optimize network URL, skipping: //1.1.1.1.1/path/site/repository/src/Web/Scripts/dashboard/almond.js
Please note that I changed the IP and the paths.
I checked the documentation of RequireJS, and in fact it does not support network URLs when optimizing.
The same script was working a few days ago.
Anybody aware of changes in Azure that could have lead to this? Any workaround?
Thanks a lot
I made it working by overriding the baseUrl when calling r.js:
node "%DEPLOYMENT_SOURCE%\build\node_modules\requirejs\bin\r.js" -o "%DEPLOYMENT_SOURCE%\build\build.js" baseUrl=%DEPLOYMENT_SOURCE%\src\Web\scripts
Related
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 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 have following problem:
I wrote a little homepage under Win10. All is fine but when I deploy my work in a Linux system I get the following message:
[2015-12-17 09:28:41] request.CRITICAL: Uncaught PHP Exception Twig_Error_Loader:
"The "/info/wwv/data/someone\vendor\symfony\symfony\src\Symfony\Bundle\FrameworkBundle/Resources/views" directory does not exist."
at /info/wwv/data/someone/vendor/twig/twig/lib/Twig/Loader/Filesystem.php line 94 [...]
I think there is some problem with the DIRECTORY_SEPARATOR or similar. The path exists and I can access it when I replace the backslashes with slashes.
Also my log is written in the directory app\logs instead real subdirectory app/logs.
Are you generating the cache on Windows and deploying the cache too instead of building it on the Linux server ? This is indeed not meant to work properly, due to differences between the OS.
Recent versions of Symfony allow to build the cache before deployment and copy it to the other server, but this does not work with Windows on one side and Linux on the other.
I had a similar issue. One day symfony 3.4 (on php7.2.16) stops working. After changing some path settings in AppKernel.php from '/' to '\\', everything works fine.
e.g.
public function getLogDir()
{
return dirname(__DIR__).'\\var\\logs';
}
It seems to be a windows-related issue with path-settings.
I had the same problem as my production server did not let me allocate enough ram to run composer and I had to run it locally.
Afterwards I got similar error (having wrong access path \ instead of / for linux)
Steps I took:
Replacing \\ with / in composer.json and composer.lock
Clearing the var/cache/*
I have a node.js project that compiles less files to css when I start the app. I do this by modifying the start script in package.json like so:
{
// omitted for brevity
start: { lessc public/stylesheets/styles.less > public/stylesheets/styles.css; node app.js; }
}
This works nicely locally, but not at all on my Windows Azure instance. Either because less needs to be installed globally on the machine for this to work, or because Azure doesn't run npm start. Or both. Either way, I need another solution!
I thought custom deployments was the answer (I'm using git remote deployment) and I tried modifying the deploy.cmd to include
call "lessc public/stylesheets/styles.less > public/stylesheets/styles.css;"
No joy. I even tried
call "%SITE_ROOT%/node_modules/less/bin/lessc %SITE_ROOT%/public/stylesheets/styles.less > %SITE_ROOT%/public/stylesheets/styles.css;
Am I coming at this the wrong way? How can I keep the compiled css files out of my source control and compile them on the server after deployment to Azure?
Thanks!
OK, I finally have this going, I think.
For some reason, even though the physical file is on the disk (I can see them with my FTP client), Azure is not letting me run lessc in the \node_modules\less\bin folder, but it does let me run the version in the \node_modules\.bin folder.
In the end, I added the following lines to my deploy.cmd file, and it worked!
IF NOT DEFINED LESS_COMPILER (
SET LESS_COMPILER=%DEPLOYMENT_TARGET%\node_modules\.bin\lessc
)
call %LESS_COMPILER% %DEPLOYMENT_TARGET%\public\stylesheets\styles.less > %DEPLOYMENT_TARGET%\public\stylesheets\styles.css
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.