Not sending non-exit code on fatal errors #8749
Comments
|
I'm having trouble reproducing the "exit code" issue (I suspected 04dc469 -- but that was added in 0.85). Every error situation I throw at it exits != 0. But I suspect I can fix the origin of this error. I'm a little puzzled why you're seeing this and not me (and others), and I don't understand the how, but I do understand the why, which I guess is good enough to fix it. |
bep
added a commit
to bep/hugo
that referenced
this issue
Jul 13, 2021
bep
added a commit
to bep/hugo
that referenced
this issue
Jul 15, 2021
bep
added a commit
to bep/hugo
that referenced
this issue
Jul 15, 2021
This commit started out investigating a `concurrent map read write` issue, ending by replacing the map with a struct. This is easier to reason about, and it's more effective: ``` name old time/op new time/op delta SiteNew/Regular_Deep_content_tree-16 71.5ms ± 3% 69.4ms ± 5% ~ (p=0.200 n=4+4) name old alloc/op new alloc/op delta SiteNew/Regular_Deep_content_tree-16 29.7MB ± 0% 27.9MB ± 0% -5.82% (p=0.029 n=4+4) name old allocs/op new allocs/op delta SiteNew/Regular_Deep_content_tree-16 313k ± 0% 303k ± 0% -3.35% (p=0.029 n=4+4) ``` See gohugoio#8749
bep
added a commit
to bep/hugo
that referenced
this issue
Jul 15, 2021
This commit started out investigating a `concurrent map read write` issue, ending by replacing the map with a struct. This is easier to reason about, and it's more effective: ``` name old time/op new time/op delta SiteNew/Regular_Deep_content_tree-16 71.5ms ± 3% 69.4ms ± 5% ~ (p=0.200 n=4+4) name old alloc/op new alloc/op delta SiteNew/Regular_Deep_content_tree-16 29.7MB ± 0% 27.9MB ± 0% -5.82% (p=0.029 n=4+4) name old allocs/op new allocs/op delta SiteNew/Regular_Deep_content_tree-16 313k ± 0% 303k ± 0% -3.35% (p=0.029 n=4+4) ``` See gohugoio#8749
bep
added a commit
to bep/hugo
that referenced
this issue
Jul 15, 2021
This commit started out investigating a `concurrent map read write` issue, ending by replacing the map with a struct. This is easier to reason about, and it's more effective: ``` name old time/op new time/op delta SiteNew/Regular_Deep_content_tree-16 71.5ms ± 3% 69.4ms ± 5% ~ (p=0.200 n=4+4) name old alloc/op new alloc/op delta SiteNew/Regular_Deep_content_tree-16 29.7MB ± 0% 27.9MB ± 0% -5.82% (p=0.029 n=4+4) name old allocs/op new allocs/op delta SiteNew/Regular_Deep_content_tree-16 313k ± 0% 303k ± 0% -3.35% (p=0.029 n=4+4) ``` See gohugoio#8749
bep
added a commit
to bep/hugo
that referenced
this issue
Jul 15, 2021
This commit started out investigating a `concurrent map read write` issue, ending by replacing the map with a struct. This is easier to reason about, and it's more effective: ``` name old time/op new time/op delta SiteNew/Regular_Deep_content_tree-16 71.5ms ± 3% 69.4ms ± 5% ~ (p=0.200 n=4+4) name old alloc/op new alloc/op delta SiteNew/Regular_Deep_content_tree-16 29.7MB ± 0% 27.9MB ± 0% -5.82% (p=0.029 n=4+4) name old allocs/op new allocs/op delta SiteNew/Regular_Deep_content_tree-16 313k ± 0% 303k ± 0% -3.35% (p=0.029 n=4+4) ``` See gohugoio#8749
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Hugo are you using (
hugo version)?Does this issue reproduce with the latest release?
Yes, this is for us reproducible since
0.84.0and persists with0.85.0.Our site is quite large and does more than 1k image resizes with HUGO which sometimes leads to a race condition (unrelated issue that we need to fix, probably caused by wrong usage). This is something we were ok dealing with, but since
0.84.0we were seeing issues that Netlify was deploying our failed builds causing our site to be down.Looking further into this, it seems that HUGO is not sending a non-exit code on build failure due to the race condition. This was working correctly in
0.83.1.I can't link to the repository of the site, as it's a private one, but here are some example log snippets:
v0.83.1v0.84.0I'm happy to provide more information and help debugging this, just let me know what is needed.
The text was updated successfully, but these errors were encountered: