This message was deleted.
# hobbyfarm
a
This message was deleted.
m
Additionally, I’ve removed the
draft
status from the PR, so it’s ready to be merged.
f
Perfect.
Do you have any more additions @worried-fountain-60974?
w
Nope I am ready for merge
🔥 1
f
Merged
i think that killed the github pages https://hobbyfarm.github.io/about/ seems like some directives are wrong @millions-lock-30385
m
The
about
page shouldn’t exist any longer. It was merged in with the primary page so that the site had content on the initial visit. I’m unsure what might have broken on the deployment. Did it look OK for you locally? Perhaps the version of Hugo is older in the pipeline build?
f
hugo-version: '0.108.0'
the about page is still linked on the left menu
m
Yeah, it shouldn’t be. Given what I’m seeing, it looks like it’s not understanding the toml file change, which is what’s telling me it’s an older version.
I used the latest Hugo to update:
Copy code
➜ hugo version  
hugo v0.119
Did you have problems reviewing it locally?
f
i will try updating the workflow to 119
👍 1
i have not viewed this locally
m
Ah, OK. That makes sense now. We should build in some e2e testing in the pipeline to ensure specific things exist and versions match, etc.
If I’m given the rights to do so, I’m happy to do some updates there.
f
what rights would you need?
i have merged the hugo update. lets see if this worked
👍 1
m
I’d need rights to update the pipeline and run tests there. I can just do it on my fork as well if that’s a problem.
f
only eamon can give you the rights for that. you can test this on the fork i beleive
m
No worries.
f
WARN Module "github.com/google/docsy" this module is not compatible with hugo 119
so this leads to errors during the build when updating hugo to 119, currenctly we had hugo 108
m
I don’t get that at all:
Copy code
➜ hugo server --navigateToChanged
Watching for changes in /home/eengelking/git/github/hobbyfarm/hobbyfarm.github.io/{archetypes,assets,content,package.json}
Watching for config changes in /home/eengelking/git/github/hobbyfarm/hobbyfarm.github.io/hugo.toml, /home/eengelking/git/github/hobbyfarm/hobbyfarm.github.io/go.mod
Start building sites … 
hugo v0.119.0-b84644c008e0dc2c4b67bd69cccf87a41a03937e+extended linux/amd64 BuildDate=2023-09-24T15:20:17Z VendorInfo=snap:0.119.0

WARN  calling IsSet with unsupported type "invalid" (<nil>) will always return false.
WARN  .File.UniqueID on zero object. Wrap it in if or with: {{ with .File }}{{ .UniqueID }}{{ end }}

                   | EN  
-------------------+-----
  Pages            | 47  
  Paginator pages  |  0  
  Non-page files   | 21  
  Static files     | 33  
  Processed images |  0  
  Aliases          |  0  
  Sitemaps         |  1  
  Cleaned          |  0  

Built in 421 ms
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at <http://localhost:1313/> (bind address 127.0.0.1) 
Press Ctrl+C to stop
f
what about
hugo --minify
?
That is used during the build
m
Copy code
➜ hugo --minify          
Start building sites … 
hugo v0.119.0-b84644c008e0dc2c4b67bd69cccf87a41a03937e+extended linux/amd64 BuildDate=2023-09-24T15:20:17Z VendorInfo=snap:0.119.0

WARN  calling IsSet with unsupported type "invalid" (<nil>) will always return false.
WARN  .File.UniqueID on zero object. Wrap it in if or with: {{ with .File }}{{ .UniqueID }}{{ end }}

                   | EN  
-------------------+-----
  Pages            | 47  
  Paginator pages  |  0  
  Non-page files   | 21  
  Static files     | 33  
  Processed images |  0  
  Aliases          |  0  
  Sitemaps         |  1  
  Cleaned          |  0  

Total in 1326 ms
Let’s do this: rollback the release to the previous commit and I’ll look into this on my fork this evening.
f
i think the old reference to google/docsy in the config.toml was the problem. i removed it and did a hugo mod tidy. now it seems to work without errors
m
There shouldn’t be a config.toml. It should be hugo.toml.
f
yes i meant that. sorry
m
OK, whew. I thought something was really borked.
f
i also changed the go.mod to 1.21
👍 1
build went through. lets look if the update to hugo 119 resolved it
the page still looks the same. so it is not about the hugo version
m
Locally, it’s fine. I’m unsure what might have broken.
f
there is still a "public" folder. is that used for the deployment?
m
Let’s revert the commit as mentioned earlier. I’ll take a look this evening on my fork.
Unsure about the public folder. I know in Gitlab, that the pages uses a public folder. I think this may be similar.
f
publish_dir: ./public
so it deploys the public dir, but it should be build using
hugo --minify
m
OK. I’ll troubleshoot this evening.
f
no worries
we might need to remove the public folder. as it seems a hugo minify does not remove existing files. thus the about page will always be there 😄
m
Ah, I see. That probably would explain things. Given that hugo is dynamically generating content, it probably makes sense to put any folder that hugo generates into the .gitignore folder so that nothing is accidentally added/committed. I was wondering about this during my work, but didn’t explore it too deeply due to time constraints.
f
yes i think someone pushed the public folder. we should delete it + as you said put in in the gitingore
👍 1
m
I’ll work on that this evening. Are we able to rollback to the previous commit?
f
if we fix this today i think it is not needed to rollback
m
OK. I’ll see what I can do. No guarantees, of course. 🙂
f
sure 😄
m
I spent a few hours this evening looking over what may be broken in the docs deployment. After review, here are my findings: • Having the
public
folder in the
main
repo may be causing some issues with caching older content, and should probably be removed. • The
hugo --minify
command doesn’t appear to be actually building/minifying files. The examples I’ve seen on my local environment do not match what’s seen in the
gh-pages
branch. For example, look at the
404.html
page. • Some of the new content has been pulled in. For example, if you look under the
gh-pages
branch, you can easily see new images I’ve added. • The
index.html
and
index.xml
files are blank under all of the category folders (ie. about, categories, community, docs, etc) • In the GH Actions workflow, the
actions/checkout@v3
should be updated to
v4
.
I think the next steps are to delete the
public
folder and try to run the actions workflow again to see if that resolves the issue or not. If it does, we should make sure that it’s put into the
.gitignore
file, along with any other content that is dynamical generated by Hugo. I’m concerned that the
hugo --minify
command isn’t doing what it should be doing in the actions workflow. It appears that something is being generated, hence why you see the blank pages being updated, but something else is broken that I don’t quite yet understand.
I’ve confirmed that cleaning up the
public
folder does appear to partially fix the issues. It generates the
index.xml
files with the respective content, but it’s still missing the
index.html
files that are generated on my local machine. Example: https://github.com/eengelking/hobbyfarm.github.io/blob/gh-pages/index.xml
It looks like the problem is with layouts. I’ll have to take a look at this tomorrow as it’s late now.
👍 1
@faint-optician-47536 OK, I have it working. The last missing piece requires an update to the docsy theme. I’ll put together a PR this afternoon.
All content now exists in my gh-pages branch. https://github.com/eengelking/hobbyfarm.github.io/tree/gh-pages
PR is submitted. I figured it out faster than expected: https://github.com/hobbyfarm/hobbyfarm.github.io/pull/25
f
Merged it. That fixed it!
m
Awesome. Glad it worked. 😄
f
Thank you!
👍 1