When I make changes to a site I use hugo server to test the changes and then build the site using hugo. Randomly the site will be built using the local paths for links and images rather than the path specified with baseURL. Building the site again after discovering this will usually, but not always fix it. This applies to hugo 153 and I tried reverting to 151. The sites use themes theme-hugo-foundation6, which I’ve fixed from time to time and kraiklyn. All the sites were originally created some time ago and it’s possible I’ve missed something that should be in the site config file.
When building your site locally for a production deployment, make sure you delete the contents of the public directory before running the hugo command.
When building the site using a CI/CD workflow (e.g., GitHub Pages, GitLab Pages, Netlify, Cloudflare, etc.) you don’t have to delete the public directory before pushing your changes, unless you have placed the public directory under source control, which you should never do.
Thank you for this. However there’s nothing in the public directory of the blog site, the other site doesn’t have one. Most of the sites I have created don’t have one. I assume the hugo new site command stopped creating them at some stage.
This is true. However I have been building sites using this method off and on since 2017 and this has only started happening recently. Because it’s random it’s difficult to pin down a hugo version where it started. This is why I said…
All the sites were originally created some time ago and it’s possible I’ve missed something that should be in the site config file.
All the sites have a baseURL and a publishDir entry in the config file. The publishDir entry points to a folder which is published via Github pages, either in the billthefarmer.github.io project or in a project docs folder.
When you run either hugo or hugo server, are running the command within one of the MS shells, or within a shell provided by MINGW64 as shown above? Or do you run the command from either/both?
It’s a MINGW64 shell provided as part of the Windows version of Git. I do all my development using it. The thing with this problem is that it happens randomly. I create some new content for one of my web pages using hugo server interactively. Stop the Hugo server with ^C, and then just type hugo to publish the content. When it happens if I do it again, the output is fine. Hugo seems to still think it’s a server, but it publishes the content to the right place with the local baseUrl. Notice the livereload.js script.
That’s a feature of the MINGW64 shell. You type in Linux style paths and they get converted to windows style paths before being passed to executables. The path in the config file is as recognised by Hugo, it’s the same folder. I think this is a red herring. d/billthefarmer.github.io is the root folder of the GitHub project that I use to publish my web pages, there are several others, the blog being one of them.
Perhaps. But is there any harm in testing to be sure? If the publishDir is within the project directory, just use a relative path (e.g., publishDir = 'foo').
In GitHub pages the publish-your-site repository is a different repository than the Hugo sources repository . Otherwise the Hugo sources would get published as if they were web pages. In my case the publish repository is in /d/billthefarmer.github.io and the sources repository is in /d/Hugo/github.io. The source for the example above is in the /d/Hugo/github.io/blog folder. The output is in the /d/billthefarmer.github.io/blog folder. All this is not particularly relevant to the stated problem that Hugo randomly creates output as if it were a server.
In GitHub pages the publish-your-site repository is a different repository than the Hugo sources repository . Otherwise the Hugo sources would get published as if they were web pages.
Many years ago, some sites used a two repository approach: one for source, one for the build artifacts. That evolved into a two branch approach: one for source, and one for the build artifacts.
For at least the last 5 years, the recommended[1] approach is a single repository where your local public directory is excluded from source control. Then use a GitHub Action as described here.
As previously described, this issue is specific to your environment. I suspect the random nature of the problem is due to mixed build artifacts in the publication directory: some artifacts are from a previous hugo server command, while other artifacts are from the current hugo command.
Historically, in its default configuration, hugo server rendered to memory, while hugo rendered to disk. With v0.123.0[2] and later, in its default configuration, both commands render to disk. Some things to investigate…
Are you clearing the publication directory every time you run the hugo command?
Are you clearing it with rm -rf path-to-publish-dir?
After clearing it, do you immediately run the hugo command, or do you wait a moment?
Is hugo server running in another console when you run hugo?
If you have a virus scanner running, have you tried disabling it, or excluding all related directories?
Recommended by the GitHub Actions team and the Hugo maintainers. ↩︎
As I’ve been using this working environment for just about everything I do, building web sites with Hugo is just an occasional documentation task, I shall stick with it. However out of interest, I have written a short bit if C to test the environment in a MINGW64 shell and in the windows shell (if you can call it that). The answer appears to depend on how you ask.