Hugo support in Cloudflare Workers

support
1

Workers will receive the focus of Cloudflare’s development efforts going forwards, so we therefore are recommending using Cloudflare Workers over Cloudflare Pages for any new projects :up_right_arrow:.

Is Hugo a capable candidate to be added to Cloudflare Workers framework support?

1 Like
2

Sure, and it’s already been requested on their Discord dev channel. Please add your name to the list.

1 Like
3

I will. Good to know.

4

This is a repository for a Cloudflare Worker test site:
https://github.com/jmooring/hosting-cloudflare-worker

The important files in the repository are:

  • build.sh
  • wrangler.toml

This is the live site:
https://hosting-cloudflare-worker.joe-mooring.workers.dev/

This site:

  1. Includes content from a Hugo module
  2. Transpiles Sass to CSS using Dart Sass
  3. Performs vendor prefixing of CSS rules using the postcss, postcss-cli, and autoprefixer Node.js packages
  4. Processes CSS files using the tailwindcss and @tailwindcss-cli Node.js packages
  5. Encodes images to the WebP format to verify that we’re using Hugo’s extended edition
  6. Includes a content file named hugö.md to verify that the Git core.quotepath setting is false [1]

  1. See issue #9810. Git’s core.quotepath setting is false if /tests/hugö has a non-zero “last modified” date. ↩︎

3 Likes
5

Interesting. Now I need to know what those of us who are already using wrangler-action to deploy our Pages project need to do. I’m using this workflow.

1 Like
6

I got this error [custom build] /bin/sh: 1: ./build.sh: Permission denied and prompted chatGPT which recommended running chmod +x build.sh and pushing to the repo. Only then did the build go through

7

Of course. The build.sh file in the example repo already has the required permissions.

8

I copied the code instead of the whole file. My bad!

One small site is deployed to workers. Two more left. All deployed now.

1 Like
10

Two things happened after moving to workers—

  1. I lost the ability to match local build time with workers. Pages had a TZ environment variable, workers has none 🚀 Feature Request: Set TZ=UTC for wrangler dev · Issue #8106 · cloudflare/workers-sdk · GitHub
  2. Pages has deploy hooks that can be triggered with external cron to rebuild the site at regular intervals. Workers has none of that and someone from CF’s support said “you can write a scheduled handler which then calls the webhook for triggering builds though”. Now I have to research how to do that and ChatGPT shows I will need another worker and a CI/CD workflow…quite convoluted.
11

You can try exporting that from the build script.

12

I can confirm that adding this to build.sh works great:

export TZ=Europe/Oslo

Place this somewhere before the hugo command.

2 Likes
13

It does work! I printed {{ time.Now }} to test.

14

Regarding scheduled builds…

I haven’t yet implemented this in the GitHub repository for the example site, but I’m pretty sure you can create a workflow (cron job) that checks out the repo, changes a file (e.g., updated_log.txt), then commits the change. This update would trigger the CF build.

15

I’ve added a workflow file to the GitHub repository for the example site. This triggers the Cloudflare Worker build at approximately 9:57 PM UTC every day.

The obvious downside of this approach is… 365 commits each year.

1 Like
16

I use Gitlab. Is it easy to adapt that code? (the GitHub pages requirement for public repos to use Pages threw me off.)
Never Mind! I decided to just move Back to GitHub. Gitlab’s UI is complicated.

17

To answer your question, you can do exactly the same thing in a GitLab repository, though the scheduling itself is not handled within the workflow file (i.e., there are two steps).

18

I tried those steps but the pipeline kept failing. I just decided to move my 37k pages content adapter site to Netlify (I use CF Pages for the other projects but file limit is 20k).

19

You are right.

This is unfortunate, but unlike GitHub, GitLab allows only one workflow file per repository. If you only need to create/update a timestamp file like the GitHub example above, this is a trivial exercise. But if you have another task (e.g., build on commit) this gets really complicated… to the point that I’m not going to spend any time on it.

20

I spent nearly 4 hours last night and today on it. But kept getting failed pipeline commits. I agree that there is no need to waste time if it works on GitHub.

21

Just a note that custom 404 error page does not work on workers. This is a limitation of workers I guess.