The chosen Jekyll build output directory doesn't work

Hi!

I wanted to let you know that the Jekyll build output directory of my choice stopped working today/yesterday. Instead of using the chosen directory, the build tool keeps using _site, a Jekyll default directory. Unfortunately, using jekyll build --destination my_name didn’t fully help as _headers stopped working then.

I got around the problem by setting the directory to _site.

Thanks,
Michał

:thinking: Not completely sure I understand. The chosen build output directory should set be the same as the one used by the tool in order for everything to work correctly, changing that directory wouldn’t magically change how the tool works, right?

What directory did you have it set to previously? Did you upgrade anything or make any changes at the time it broke?

I haven’t made any changes to the settings whatsoever. I simply Git pushed new changes and a build “succeeded”. However, the page started returning 404. I’ve checked the build logs and I noticed: Destination: /opt/buildhome/repo/_site instead of Destination: /opt/buildhome/repo/dist (dist was my build output directory). It smells like a bug.

Thanks. Did you catch the Jekyll version on either of those logs, and do you have deployment IDs for both? The IDs should be visible at the end of the dashboard path when you’re viewing the logs.

Unfortunately, I don’t have the one with dist. I’ve removed and re-added the application while debugging 404.

Version: jekyll 4.3.3
Example deployment IDs: 669dc827, 0a841677, 63ba1f9f

Those would be the short form of the ID, would need the full one:

The Pages deployment ID is a unique build identifier.
It’s the UUID in the browser bar (for example, a URL would be dash.cloudflare.com/ACCOUNT_ID/pages/view/PROJECT/DEPLOYMENT_ID where the deployment ID looks something like a398d794-7322-4c97-96d9-40b5140a8d9b).
This ID can help troubleshoot some issues with Pages builds so if you have a failing build make sure you grab that ID for the team to use.

Though I’m not totally sure how helpful it would be if the team doesn’t have one with dist to compare to…

669dc827-24cd-424a-a4c7-8a8f142ce4a2
0a841677-1c43-4748-a5d9-d8c86502a863
63ba1f9f-926f-4538-b4f2-7366531d2217

Though I’m not totally sure how helpful it would be if the team doesn’t have one with dist to compare to…

Well, it’s quite easily reproducible. Just create a new application with Jekyll and change the build output directory to something other than _site. The build will succeed; however, it’ll use the default directory _site instead of the one of your choice. On the other hand, the page will be served from the one you chose and that’s why you’ll get 404.

But that’s intentional behaviour. If you set the build directory to the directory other than where your tool builds the site, then it will not upload your site. You are supposed to configure it to deploy where the tool puts the site.

What I thought seemed weird was when you had dist and it worked, because it should have always been _site that was the needed option.


I just set the custom name here. I had dist before and worked perfectly fine. The build used dist. Now it uses _site even if I set whatever_else.

Yep, understood you and that is strange! Hence why I was after a deployment ID of it succeeding when it shouldn’t to share with the Pages team in case there was any differences between the two. Since putting dist in there currently fails to reproduce a success, I fear there wouldn’t be much to do further in terms of debugging without said ID of one such case.

Not sure if I’m following. If you put dist now the build will succeed (but will use _site instead of dist) and the page will start returning 404.

Yes but that would be the intended behaviour. Because Jekyll is not deploying the site to dist. What would be needed is a case which as you put it, “worked perfectly fine”.

OK, but what is the problem of debugging and fixing something that clearly doesn’t work?

The thing is that the build tool should build output to the directory name of my choice and serve it from there. Currently, entering anything other than _site simply breaks the page and returns 404.

That’s not how Cloudflare Pages works. The build directory has to be set to where the files are output. It is not passed to the tool and the tool puts the files where it wants. You set the output directory to match.

Because it’s the intended behaviour - Jekyll doesn’t deploy to dist, so putting dist is not expected to work and can’t be fixed. The build configuration value has to be where the site is, you can’t go setting it to unrelated directories. So reproducing that behaviour doesn’t tell you anything.

The fact it worked before would be the bug, but without evidence in the form of a deployment ID that can’t begin to be debugged. There would be important factors such as maybe the Jekyll version was different on that build?

Got it. So, the behavior I experienced was a bug, which now seems to work as expected.

There would be important factors such as maybe the Jekyll version was different on that build?

Nope, the same version. I didn’t change a single thing.

Maybe, the tool was setting jekyll build --destination … based on the output directory. But it’s just purely guessing without any evidence.

We do not change the build command, the one specified is the one we run. If it’s jekyll build we’ll run that and not change it.

1 Like

But, even if I set dist as the output directory and use jekyll build --destination dist, the page works, but _headers are not attached. Is it expected?

Are these _headers generated by Jekyll or supplied by you? If they’re yours, where are you putting them?