Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Feb 24 20:20
    dependabot[bot] labeled #246
  • Feb 24 20:20
    dependabot[bot] opened #246
  • Feb 24 20:20

    dependabot[bot] on bundler

    Bump nokogiri from 1.10.5 to 1.… (compare)

  • Feb 22 01:53
    Ecco opened #1487
  • Feb 21 20:11
    Ecco edited #1486
  • Feb 21 20:10
    Ecco edited #1486
  • Feb 21 20:10
    Ecco opened #1486
  • Feb 13 04:43
    codemer commented #1485
  • Feb 13 04:38
    codemer commented #1485
  • Feb 12 08:11
    ddfreyne commented #1485
  • Feb 12 08:07
    ddfreyne commented #1482
  • Feb 12 07:59

    ddfreyne on master

    Make Checksummer spec for Proc … (compare)

  • Feb 12 07:53

    ddfreyne on rm-safe-level

    (compare)

  • Feb 12 07:52

    ddfreyne on master

    Remove safe_level support in ER… Merge pull request #1481 from n… (compare)

  • Feb 12 07:52
    ddfreyne closed #1481
  • Feb 12 07:40
    ddfreyne synchronize #1481
  • Feb 12 07:40

    ddfreyne on rm-safe-level

    Remove safe_level support in ER… (compare)

  • Feb 12 07:39

    ddfreyne on master

    Make Checksummer spec for Proc … (compare)

  • Feb 12 07:39

    ddfreyne on master

    Regenerate .rubocop_todo.yml (compare)

  • Feb 12 07:37
    ddfreyne synchronize #1481
Tim Hosgood
@thosgood
huh, makes no difference either way
Ian Young
@iay
It shouldn't matter where you run ssh-add. It pulls your key from the ~/.ssh/ directory anyway, unless you add extra command line arguments.
Tim Hosgood
@thosgood
no, still getting the same error
are there any other logs I can give? has nobody else had this problem?
I’m absolutely loving nanoc! but this is my only minor bug
should I make an issue on the repo?
Denis Defreyne
@ddfreyne
This seems to be related to Git/SSH and probably not on the Nanoc side
@thosgood Can you try out this: after running nanoc deploy and getting an error, cd into public/, then do a git push — do you get the same error then?
Tim Hosgood
@thosgood
huh, no, the git push seems to work fine
but the nanoc deploy error says that it can’t do a git pushbecause of a permissions problem
so it’s trying to do the push itself
which makes it seem even weirder to me: we run it twice, the second time there’s no error, which would imply that it has done the push, but then i still have to push by hand?
so is it just not even trying to do the push the second time or what?
and if it is, then what exactly is it pushing...
Screenshot 2019-10-09 at 03.26.19.png
Denis Defreyne
@ddfreyne
@thosgood Hmmm… what if you configure nanoc.yaml and set remote to be origin (rather than git@github…)
git push will use the default remote (which would be origin) so maybe there’s some remote funkiness
Tim Hosgood
@thosgood
yes!
that fixed it perfectly, thank you!
must have been some mistake in how I set the remote
Andri Möll
@moll
I've noticed nanoc live --live-reload often ends in a situation where an edit causes a refresh, but the refresh happens before the new version of a page has been written to disk. Live-reload therefore gets shown a 404 page. Apart from just playing with the LiveReload delay option, do we have any smarter solutions?
Andri Möll
@moll
I'm using guard-nanoc for the live command.
Seems https://github.com/ddfreyne/adsf/blob/master/adsf-live/lib/adsf/live/watcher.rb is responsible for setting up LiveReload, and it hard-codes the delay to 0, along with hard-coding the port.
I think the port should be randomized to permit multiple instances of LiveReload to be running on the same computer.
Denis Defreyne
@ddfreyne
Hmmmmm… but livereload is supposed to reload when it detects changes to the compiled site only, so maybe something else is going wrong here
Andri Möll
@moll
How does Nanoc write an output file? Straight over the existing file or does it use a temporary file with renaming?
Denis Defreyne
@ddfreyne
@moll It uses a temporary file
Andri Möll
@moll
That would explain why it's triggering LiveReload before it's finished.
If that temporary file is placed in the same output directory.
Nanoc could place it in tmp and rename from there. That'd fix early reloads. Better though probably to hook into LiveReload and trigger it once compilation is finished, but I don't know whether the LiveReload library permits that.
Denis Defreyne
@ddfreyne
Hmm no, it’s written into /tmp/* and then moved into place
Andri Möll
@moll

Mkay, I'll run inotifywait next time I'm working on my site and confirm what Nanoc's doing. Perhaps a directory gets touched (by the kernel) first, triggers inotify and LiveReload catches that.

You're claiming Nanoc's renaming files over existing files, right? It's not a delete-then-move action?

Presumably at some point the output file has to be missing entirely, otherwise the web server wouldn't report a 404.
Denis Defreyne
@ddfreyne
Hmmm, it should be in place!
This is pretty weird.
Andri Möll
@moll

Curiously, I'm seeing a delete happen ...

19:51:36 DELETE public/articles/foo/index.html
19:51:36 CREATE public/articles/foo/index.html
19:51:36 MODIFY public/articles/foo/index.html
19:51:36 CLOSE_WRITE,CLOSE public/articles/foo/index.html

This with:

inotifywait --recursive --monitor public --format "%T %e %w%f" --timefmt "%T" -e modify -e attrib -e close_write -e moved_to -e moved_from -e move -e move_self -e create -e delete -e delete_self
And that triggered a race which LiveReload won, reloading before the create and coming up with "File not found".
Andri Möll
@moll
I think I know why this is happening. Nanoc's not using renaming, it's using hard linking.
https://github.com/nanoc/nanoc/blob/4.10.1/nanoc/lib/nanoc/base/services/item_rep_writer.rb#L59 calls FileUtils.ln with force: true. Force, as per Ruby's implementation, just unlinks it before creating a new link:
https://ruby-doc.org/stdlib-2.4.1/libdoc/fileutils/rdoc/FileUtils.html#method-c-ln
That explains the delete inotify event before create and explains the race condition.
Andri Möll
@moll
Why's Nanoc using linking or copying there in the first place? Wouldn't it be fine to move the temporary file? I suppose it's because you were trying to optimize by hard linking binary files.
..given that in one branch of the code temp_path is set to not a true temporary path, but the actual filename from the content directory.
Denis Defreyne
@ddfreyne
@moll The hardlinking’s purpose is to improve disk usage
Moving stuff in place can work under certain conditions, but not all
(e.g. the input file in content/ might be hardlinked to what is in output/!)
Andri Möll
@moll
Are you saying that non-binary items are hardlinked from content? From my brief reading I got the impression compiled items are just written to tmp, then hardlinked, then removed from tmp.
Denis Defreyne
@ddfreyne
Non-binary items are not hardlinked from content.
Andri Möll
@moll
Are compiled items stored somewhere aside from the output directory? I didn't notice any in my tmp...
Denis Defreyne
@ddfreyne
The intermediate compiled files are stored in the OS’ temporary directory (/tmp somewhere)
Andri Möll
@moll
For a long time or just during a single compile?
Denis Defreyne
@ddfreyne
During a single compilation