Recommended approach for deleting generated pages

Background:
I build my site to a separate repo (GitHub Pages). If I delete a source markdown page, I want the corresponding built HTML page to be deleted during the build.

I’m familiar with --cleanDestinationDir (hugo usage). The undesirable result of that option is that each commit of the built site deletes every file and then adds every file. This seems a bit inefficient, but it also means I can never see a diff of my builds.

I’m also familiar with the default behavior around draft, publishdate, and expirydate. However, I don’t see how expirydate is useful if the default behavior doesn’t remove the built page that has expired. In order for the expirydate behavior to be useful, don’t you have to also use the --cleanDestinationDir option? If so, the documentation should mention this.

Current Solution:

My current solution is to build to a temporary directory, then use rsync between the tmp build directory and the final repo destination. This ensures that a page that was not built to the tmp directory will actually get deleted (using the --delete option for rsync) from the final repo.

Problem:

However, now I’m dealing with .gitignore getting deleted and unwanted files in my build directory.

Can anyone comment on this general approach or share their solutions? Is there a better way to do this? I feel like I shouldn’t need rsync to make this work the way I want. Thoughts?

not from the source.

just .gitignore the public folder

2 Likes

Instead of source in one repo, and the built site in another repo, have you considered this approach instead? It builds to another branch (the gh-pages branch) instead of building to another repo.

1 Like

@divinerites I don’t build to public.

Here’s my build command:

hugo -v --ignoreCache --cleanDestinationDir --enableGitInfo -d /tmp/site/

Here’s my rsync command:

rsync -avh --filter='P .git' --filter='P CNAME' -exclude-from=sync_ignore.txt --backup --backup-dir=/tmp/site-bak/ /tmp/site/ /dst/site --delete

@jmooring No, not an option. My Hugo repo is private and the site repo is public.

OK so .gitignore whatever you build to.

Git version control id for source code not for generated code

1 Like

You can keep the repo private.

The solution I’m hearing from you guys is to not care about the commit history of my generated site. That’s fair. I’ll consider that. However, I still use the commit review to spot-check that the build worked as expected. I guess I’m paranoid about that. I’ve been burned enough times by various anamolies in my own setup.

That said, the core of my question is really around the use of --cleanDestinationDir and expirydate. Is it accurate to say that --cleanDestinationDir is the recommended way to remove pages from the built site? From what I can tell, expirydate and draft: true on their own will not remove a previously built page.

I have to agree with others here, checking in built assets seems completely wrong to me.

If you’re looking to prevent broken releases to your production server then set up deploy preview branches. I have a protected main branch that deploys to production, whilst my develop branch deploys on push. If that breaks, I don’t merge develop into my production branch. Git flow is your friend.

2 Likes

@nternetinspired How do you use GitHub Pages without checking in built assets?

I’ll reiterate that my question is not really about .gitignore or where to build my site. My question is about how to delete a page from the built site.

That said, the core of my question is really around the use of --cleanDestinationDir and expirydate . Is it accurate to say that --cleanDestinationDir is the recommended way to remove pages from the built site? From what I can tell, expirydate and draft: true on their own will not remove a previously built page.

Deleting a generated page is done with the parameters you identify. I works flawlessly. Removed before generating a new one.

Your “problem” is that you want to use version control on your generated pages.

But you seems to keep on mixing the two question i guess.

--cleanDestinationDir is about the generated pages folder
expirydate and draft are about the source content/pages and how they behave.

I will stop trying to give advices here.

I just nuke the entire build directory using a prebuild script defined in package.json

"scripts": {
    "build": "npm run build:webpack && npm run build:hugo",
    "build:webpack": "NODE_ENV=production webpack --config webpack.prod.js",
    "build:hugo": "hugo -d ./public --gc --minify --templateMetrics",
    "dev": "run-p dev:**",
    "dev:webpack": "TAILWIND_MODE=watch NODE_ENV=local webpack serve --config webpack.dev.js",
    "dev:hugo": "hugo -d ./public -w --buildDrafts --templateMetrics --templateMetricsHints --watch",
    "lint": "eslint src",
    "preview": "run-p preview:**",
    "preview:hugo": "npm run start:hugo -- -D -F",
    "prebuild": "rimraf public",
    "test": "echo \"Error: no test specified\" && exit 1"
  },

Shiny fresh new site every time. Easy.

I don’t use GH Pages, but if I did I would do it the same way. Push my changed source to Github and have a GH action do the build.

Thanks for confirming the best practice and expected usage. Docs PR created.