I've the following environment: One Apache2 Webserver on an Ubuntu machine with three vhosts (one vhost per project). Those three project run all on Symfony2 (but differnt versions, from 2.2 to 2.4). Each of the projects (and its paths) have an own user. I'm deploying the projects with capifony on this server, each has an own receipt.
Sass version Sass 3.2.14 (Media Mark)
Imagine I'm deploying application 1 to the Webserver. When the deploymentprocess comes to dumping all production assets, its writing the temporary generated sass files into the following folder:
/tmp/600d657f6ac2358f30ba6bc0ab4cd7ffb6194ced
as user1.
If I'm deploying now application 2 to the Webserver, dumping the assets would like to write into the exactly same folder, this time as user2 and the following error occurs:
An error occurred while running: * [err :: 10.0.106.103] '/usr/bin/ruby' '/usr/local/bin/sass' '--load-path' '/srv/vhosts/myproject.com/releases/20140619124055/app/../web/sass' '--scss' '--cache-location' '/tmp' '/tmp/assetic_sassbsrcle' * [err :: 10.0.106.103] * [err :: 10.0.106.103] Error Output: Errno::ENOENT: No such file or directory - /tmp/600d657f6ac2358f30ba6bc0ab4cd7ffb6194ced/assetic_sassbsrclec20140619-27927-aw8xrk.lock
My workaround currently is, to remove this /tmp/600d657f6ac2358f30ba6bc0ab4cd7ffb6194ced folder every time before deployment.
I didn't find any pathconfiguration in the capifony receipts nor in the Symfony2 config files in all projects.
Any help is appreciated.
Best, Ramo
This has been referenced on the official assetic repository as an issue, as well. Since you can set sys_get_temp_dir() via the environment variable TMPDIR (among others), I would recommend doing that for your dump. You could base it off the current unix time, or the commit you're deploying, or a combination of the application, time, and intent. Really, anything could work. The line responsible for setting the cache location is here, in case you wanted to fork Assetic and change that, which is quite doable as well. I would suggest the TMPDIR route at first to confirm a potential fix.
Small edit, there is also this pull to semi-address this issue.