Not processing files without front-matter properly

[mrmanc]

@mrmanc , unfortunatly that didn't work. The webserver came up, but only gave me a file list but would never create the hosting files.
I am unsure if the problem is because of this warning,

github-pages-1 | Auto-regeneration may not work on some Windows versions.
github-pages-1 | Please see: microsoft/WSL#216
github-pages-1 | If it does not work, please upgrade Bash on Windows or run Jekyll with --no-watch.

or because of

! github-pages The requested image's platform (linux/arm64) does not match the detected host platform (linux/amd64/v3)

Ironically I usually use macOS (as arm64), but this particular project is Windows only so I am normally wirting docs on my Windows machine 😅

Originally posted by @beeradmoore in Starefossen/docker-github-pages#74 (comment)

[mrmanc]

@beeradmoore I hope you don’t mind that I’ve moved this conversation here as it didn’t feel directly related to the other issue, and I think keeping the other issue relevant will increase the amount of people who spot the availability of an alternative to the broken image.

I’m not sure which of those messages are relevant to your issue. Can I first ask you to show what your docker-compose.yml file looks like, and whether your documentation files are in the root of the repository, or in a docs/ directory?

[beeradmoore]

Hey, no worries, makes sense to move it here.

I had a compose.yml (is it meant to be docker-compose.yml?) in the docs/ folder instead of in the root and point to the docs.

I have a Gemfile and Gemfile.lock in the docs folder. I can try move them all to the root and use your original.

services:
  github-pages:
    volumes:
      - './:/src/site/'
    ports:
      - '4000:4000'
    image: markcrossfield/pages-gem:231-alpine

The repo I was using it on is diss-swapper, specifically the feature/custom-directories branch.

Your composer file was not committed, the ones in the docs/ folder are what I threw together based on that other thread. It seems to work, but yours is a little different. If yours is the correct way the ruby gems are setup and its more true to form of GitHub Pages I'd love to use it over what I have.

EDIT: I tested on my macOS machine. No more ARM64 errors, no more the error, but it still does not work in the above setup. http://localhost:4000/index.html is not found, http://localhost:4000/index.md serves the raw md file as expected, http://localhost:4000 shows a directory listing of my docs folder.

In terms of output,

2024-10-01 08:28:39 Configuration file: /src/site/_config.yml
2024-10-01 08:28:39             Source: /src/site
2024-10-01 08:28:39        Destination: /src/site/_site
2024-10-01 08:28:39  Incremental build: disabled. Enable with --incremental
2024-10-01 08:28:39       Generating... 
2024-10-01 08:28:39       Remote Theme: Using theme pages-themes/slate
2024-10-01 08:28:40                     done in 0.572 seconds.
2024-10-01 08:28:40  Auto-regeneration: enabled for '/src/site'
2024-10-01 08:28:40     Server address: http://0.0.0.0:4000
2024-10-01 08:28:40   Server running... press ctrl-c to stop.not found.

and when I tried to go to index.html it produced this error

2024-10-01 08:28:52 [2024-09-30 22:28:52] ERROR `/index.html' 

EDIT 2:
I committed compose.yml into the root directory. That is the one that does not work, if you go into docs/ folder and try the compose.yml in there it does work.

[mrmanc]

Yeah, it also failed on my Macbook. It worked with my native jekyll v3.9.0 binary though, running under ruby v2.7.2.

I could see that the files are available in the container, but running jekyll build v3.9.5 under ruby v3.3.3 seemed not to process the md files. That rang a weird bell, so I tried adding frontmatter to your .md files specifying a default layout. Then it worked.

I don’t usually skip the frontmatter in my files, but you can do with these two plugins which GitHub Pages supports:

• jekyll-optional-front-matter plugin
• jekyll-default-layout

They can be specified in your _config.yml file in the plugins section:

plugins:
- jekyll-remote-theme
- jekyll-default-layout
- jekyll-optional-front-matter

Doing that also makes your site work with the image I published.

I don’t fully understand why with your files as they are, your Dockerfile.alpine works, my local Jekyll works, and my published image doesn’t. I’ve build and tested a new image and I get the same results. It looks like those plugins aren’t getting enabled by default when running GitHub’s pages-gem Docker container for some reason. I don’t feel it’s worth me investigating any further right now, so I’ll suggest you either change your config or use your own Dockerfile.

If yours is the correct way the ruby gems are setup and its more true to form of GitHub Pages I'd love to use it over what I have.

Nope, your way is fine. The way I suggested just avoids you having to include a Dockerfile in your repo.

[beeradmoore]

Thanks for the info.

Updating the _config.yml as you said got the site rendering correctly.

I still had the other issue of Windows not refreshing the content. Comparing our Dockerfiles I can see the final command was slightly different. I appended this to the bottom of your compose.yml and it seemed to reload the work over time. I still needed to manually refresh the browser, unsure if that is required on macOS.

command:  jekyll serve --watch --force_polling -H 0.0.0.0 -P 4000"

It does take a while for it to realise the change. I assume there is a parameter to change the polling duration, and probably can speed up building with --incremental.

It is running incredibly slow, however I think that is just it trying to run arm64 on my x86_64 machine.

The entire thing isn't perfect, but it works plenty enough to get the job done. It's a shame GitHub is no longer supporting theirs as it would have been nice to have them maintain it and adjust as they adjust the build system for GitHub Pages.

But at least this works, and when in doubt test in prod 😅

[mrmanc]

Thanks for your reply. I’ve been supporting someone else using Windows today, and I found it was incredibly slow. I’ve added the info about using --force_polling to the info on dockerhub, and also published a multi-platform image that might support your platform better (versions 232-alpine and latest-alpine now support linux/amd64). Have a go and see if it runs faster (and let me know!).

[mrmanc]

For info: I confirmed yesterday that the force polling option works on Windows, and also that the speed is remarkably better with the correct architecture (reduction of ~173s to ~1.5s).