Surfer CLI 5.11.0 fails to upload
-
Hi,
I guess I should more often update my blog as I only now noticed that the current surfer version fails at uploading. Downgrading surfer back to 5.10.4 makes uploads succeed again.
The following trace is written:
+ surfer --version 5.11.0 + surfer put --token $SURFTOKEN --server blog.9wd.eu public/. / Using server https://blog.9wd.eu /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:63 atime: stat.atime.toISOString(), ^ RangeError: Invalid time value at Date.toISOString (<anonymous>) at collectFiles (/usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:63:27) at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:277:40 at Array.forEach (<anonymous>) at Command.put (/usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:273:15) at Command.listener [as _actionHandler] (/usr/local/lib/node_modules/cloudron-surfer/node_modules/commander/index.js:426:31) at Command._parseCommand (/usr/local/lib/node_modules/cloudron-surfer/node_modules/commander/index.js:1002:14) at Command._dispatchSubcommand (/usr/local/lib/node_modules/cloudron-surfer/node_modules/commander/index.js:953:18) at Command._parseCommand (/usr/local/lib/node_modules/cloudron-surfer/node_modules/commander/index.js:970:12) at Command.parse (/usr/local/lib/node_modules/cloudron-surfer/node_modules/commander/index.js:801:10)
At both times surfer is run from the following base image:
node:lts-alpine3.12
-
Hm in this case it actually is only local to the cli. Strange, it looks like the Stats object returned by nodejs has some invalid Date set on atime. I didn't know that can even happen.
Can you maybe put a
console.log(stat, stat.atime, typeof stat.atime)
or so in that code path? -
Since this is a docker image in a ci pipeline I opted to just run the stat command manually and indeed the timestamp is way off:
+ surfer --version 5.11.0 + stat public/. File: public/. Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 811h/2065d Inode: 6471947 Links: 14 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 1754-08-30 22:43:41.000000000 Modify: 2020-12-09 12:33:55.000000000 Change: 2020-12-09 12:33:55.000000000 + surfer put --token $SURFTOKEN --server blog.9wd.eu public/. / Using server https://blog.9wd.eu /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:63 atime: stat.atime.toISOString(), ^ ...
Afterwards I did
touch
that directory, but then I get a different error message afterwards from surfer:+ surfer --version 5.11.0 + stat public/. File: public/. Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 811h/2065d Inode: 6471994 Links: 14 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 1754-08-30 22:43:41.000000000 Modify: 2020-12-09 13:05:22.000000000 Change: 2020-12-09 13:05:22.000000000 + touch public/ + surfer put --token $SURFTOKEN --server blog.9wd.eu public/* / Using server https://blog.9wd.eu /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:315 if (remote.filePath !== path.join(absoluteDestPath, local.filePath)) return false; ^ TypeError: Cannot read property 'filePath' of undefined at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:315:75 at Array.find (<anonymous>) at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:314:33 at Array.filter (<anonymous>) at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:313:36 at Request.callback (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:894:12) at /usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:1127:20 at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/parsers/json.js:22:7) at Stream.emit (events.js:314:20) at Unzip.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/unzip.js:53:12)
-
Interesting behavior. For a start I've published the latest cli version to npm (so cloudron-surfer@5.12.1 )
This version has the syncing/uploading parts rewritten to avoid re-uploading unchanged files.
Could you update this and see where it breaks then? -
Updating is easy.
+ surfer --version 5.12.1 + stat public/. File: public/. Size: 242 Blocks: 0 IO Block: 4096 directory Device: 21h/33d Inode: 4999809 Links: 1 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 1754-08-30 22:43:41.000000000 Modify: 2020-12-09 13:41:18.000000000 Change: 2020-12-09 13:41:18.000000000 + touch public/ + surfer put --token $SURFTOKEN --server blog.9wd.eu public/* / Using server https://blog.9wd.eu /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:324 if (remote.filePath !== path.join(absoluteDestPath, local.filePath)) return false; ^ TypeError: Cannot read property 'filePath' of undefined at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:324:75 at Array.find (<anonymous>) at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:323:33 at Array.filter (<anonymous>) at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:322:36 at Request.callback (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:894:12) at /usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:1127:20 at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/parsers/json.js:22:7) at Stream.emit (events.js:326:22) at Unzip.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/unzip.js:53:12)
-
Hm looking at the code I can't seem to figure out how that could ever be undefined, I need to debug this and thus be able to reproduce it. Do you have any idea how we could do that?
Given the otheratime
issue, I am a bit worried about either the node version in your image or some other stripped down dependency causing this. I don't want to put code guards in to just not make it crash without understanding the root cause.I guess I have to spin up a
node:lts-alpine3.12
container and see if I can reproduce this, or do you have your exact setup as a public image I could just docker pull? -
The timestamp issue seems to be already known for Hugo (which is what I am using for my blog): https://github.com/gohugoio/hugo/issues/6161
You could pull my image from https://hub.docker.com/r/fbartels/cloudron-surfer.
If you think this could have something to do with the alpine image I am also open to converting it into a Debian based one.
-
@nebulon Also experiencing this issue (Surfer CLI 5.12.1). Seems to happen with Hugo. Last I tried with Gridsome it worked.
/usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:324 if (remote.filePath !== path.join(absoluteDestPath, local.filePath)) return false; ^ TypeError: Cannot read property 'filePath' of undefined at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:324:75 at Array.find (<anonymous>) at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:323:33 at Array.filter (<anonymous>) at /usr/local/lib/node_modules/cloudron-surfer/cli/actions.js:322:36 at Request.callback (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:894:12) at /usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/index.js:1127:20 at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/parsers/json.js:22:7) at Stream.emit (events.js:315:20) at Unzip.<anonymous> (/usr/local/lib/node_modules/cloudron-surfer/node_modules/superagent/lib/node/unzip.js:53:12)
-
Hm I can't really reproduce this on my side, neither with using @fbartels alpine based image nor otherwise.
Maybe I am misunderstanding the use-case though, so if I simply run:
run fbartels/cloudron-surfer:5.12.1 surfer put --server https://files.nebulon.space --token $TOKEN /var/ /
this works just fine.
-
In my case the surfer container is run as part of a Drone pipeline, so the
pwd
is/drone/src
at the time of execution. Based on @vjvanjungg comment I also tried it now directly on my system and while an almost blank Hugo blog succeeds in uploading with the server cli, a build of my blog shows the exact same error (maybe that makes it easier to debug, since I can then easily modify files).@nebulon said in Surfer CLI 5.11.0 fails to upload:
Maybe I am misunderstanding the use-case though, so if I simply run:
yes, almost. except that I am using a
*
to upload all files in that folder.Hmm. also their example site uploads just fine... https://github.com/gohugoio/hugoBasicExample. So it must be something in relation to the file that get generated for my blog.