Closed fruitl00p closed 4 years ago
Can you solve this by symlinking you CI's cache sub folder to .next/cache
? An option you are suggesting may be a source of many bugs and questions, hence is generally undesired.
@kachkaev i understand. From the outset this seemed really intuitive but I understand your hestitation... The symlink would work just the same I guess... Should I send a PR for the md file?
We're not currently planning on making this directory configurable. I'm going to close this since there hasn't been a lot of traction on it.
The symlink option above might be your best bet!
I only saw this today, would also appreciate the ability to change the cache dir with an env-variable. We are using a caching strategy that is different from the default way GitLab provides, and thus we need to change the cache dir. Looks like we have to hack around this using a symlink.
I would also appreciate this feature. I use Nix to deploy a Next site and with Nix packages (i.e. the site) is expected to be read-only to make it immutable (for reproducibility etc etc, checkout NixOS/Nix!).
At the moment I hack around the issue by copying the project to /tmp
then chmod -r +w .next
and running the app from there.
It would be good to be able to separate the source and the cache, especially in regards to CI.
I'm running next.js in a google cloud function and the only writeable part of the file system is /tmp
. Would be great to be able to point the cache there.
Having the exact same issue running Next.js in a Google App Engine environment, where only /tmp
is writable
@artoale Did you have a solution for this one? Considering moving our marketing site to AWS temporarily over this. Can't use next/image on GCP GAE.
@patrickmccallum - sort of - we ended up running Next.js as a custom server, manually handling requests to /next/_image?...
, which we now handle with a copy of the optimizer that uses google cloud storage instead of the filesystem to store data.
I've been having the exact same issue with Next 10.1.1 running on AWS Lambda using Serverless. It keeps wanting to write files to or delete files from .next
, causing the OS to throw EROFS (read-only file system) errors. This is regardless of what mode it's in (serverless or not), whether it runs through serverless-webpack, whether it's deployed as a Zipball or Docker container, even if .next
is symlinked into a directory in /tmp
. At my wit's end to be honest, Next has never given me this much trouble before.
To be more specific, the files that it's trying to write or delete are BUILD_ID
, export-marker.json
, and other similar highwater or JSON files within the top-level .next
directory.
I'm thinking about trying again but rebuilding the entire app in /tmp
. If it wants to write to the filesystem that badly, let's let it. Will let you know how it went. Only other way I can see is exporting it as a static bundle and dumping it on S3...
@artoale Did you have a solution for this one? Considering moving our marketing site to AWS temporarily over this. Can't use next/image on GCP GAE.
If you really need to deploy to GCP GAE, you can set your application to a flex environment.
@artoale Did you have a solution for this one? Considering moving our marketing site to AWS temporarily over this. Can't use next/image on GCP GAE.
If you really need to deploy to GCP GAE, you can set your application to a flex environment.
You can, but you wouldn't benefit from the same scalability capabilities as the standard environment, or the ability to downscale automatically to 0 instances (thus not paying anything from here) that comes from the standard environment.
This is a problem when trying to use Nix and next.js, since the config directory would be in the Nix store it would not be writable. +1 on this feature request!
I would also appreciate this feature. I use Nix to deploy a Next site and with Nix packages (i.e. the site) is expected to be read-only to make it immutable (for reproducibility etc etc, checkout NixOS/Nix!).
At the moment I hack around the issue by copying the project to
/tmp
thenchmod -r +w .next
and running the app from there.
@fmnxl Did you find an alternative?
@siraben I use this ugly hack for next.js + nix:
let
stateDir = "/var/lib/my_project";
httpPort = 8080;
in
{
systemd.tmpfiles.rules = [
"d '${stateDir}' 0750 ${user} my_project - -"
"d '${stateDir}/web-app' 0750 ${user} my_project - -"
# "d '${stateDir}/web-app/.next' 0750 ${user} my_project - -"
];
users.users = {
my_project = {
description = "my_project Service";
home = stateDir;
useDefaultShell = true;
group = "my_project";
isSystemUser = true;
};
};
users.groups.my_project = { };
systemd.services."my_project-front" = {
enable = true;
script = "node_modules/.bin/next start -p ${toString httpPort}";
environment = {
USER = user;
HOME = stateDir;
};
preStart = ''
chmod -R u+w ${stateDir}/web-app
rm -rf ${stateDir}/web-app/*
rm -rf ${stateDir}/web-app/.next
mkdir -p ${stateDir}/web-app/.next/cache
mkdir -p ${stateDir}/web-app/.next/server
find ${my_project}/web-app -mindepth 1 -maxdepth 1 -not -path "*/.next" -exec ln -s {} ${stateDir}/web-app/ \;
find ${my_project}/web-app/.next -mindepth 1 -maxdepth 1 -not -path "*/.next/cache" -not -path "*/.next/server" -exec ln -s {} ${stateDir}/web-app/.next/ \;
find ${my_project}/web-app/.next/server -mindepth 1 -maxdepth 1 -not -path "*/.next/server/pages" -exec ln -s {} ${stateDir}/web-app/.next/server/ \;
cp -L -r ${my_project}/web-app/.next/server/pages/ ${stateDir}/web-app/.next/server/
chmod -R u+w ${stateDir}/web-app
'';
serviceConfig = {
User = user;
WorkingDirectory = "${stateDir}/web-app";
ReadWritePaths = [ stateDir ];
Restart = "always";
CacheDirectory = "my_project";
PrivateTmp = true;
};
wantedBy = [ "multi-user.target" ];
after = [ "network.target" ];
};
}
why this issue has been closed?
It seems the feature has not been implemented yet, would be greatly useful!
This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
Feature request
Hi! I'd like to propose a small idea that would allow developers to alter the location of the
.next/cache
directory in order to implement the solution for no-cache in another way that doesnt seem documented: an environment variable. (or something like the way Yarn does ityarn config set cache-folder [location]
)Is your feature request related to a problem? Please describe.
This request stems from the fact that some CI providers dont have the features like Circle-CI have to easily configure the directories that should be stored between builds (but instead provide a environment variable that points to a root folder what will be persisted, i.e. Wercker does this)
Describe the solution you'd like
By having a simple environment variable that can be read during the
npm run build
this would effectively allow a developer to change / utilize a specific location for storing the cache. This could ofcourse default to.next/cache
but woudl also ease the other CI examples as mentioned on theno-cache.md
-page.Thanks!