timovv / notion-website-template

Make a personal website using Notion and GitHub Pages

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Build script flakiness

timovv opened this issue · comments

Sometimes the build script fails on the deploy step, complaining that the dist/site directory does not exist. I can think of two possible reasons:

  • For some reason either Loconotion isn't outputting where it should, or;
  • The Docker volume is not mounting as it should.

Hi @timovv, I tried to use the build script, and yes the error showed dist/site directory does not exist

Any solution I might could follow up? thanks!

commented

Same thing here

deploy.sh logs...

Run git config --global user.name "github-actions[bot]"
  git config --global user.name "github-actions[bot]"
  git config --global user.email "99999+github-actions[bot]@users.noreply.github.com"
  
  GIT_DEPLOY_DIR=dist/site \
  GIT_DEPLOY_BRANCH=gh-pages \
  GIT_DEPLOY_REPO="https://***@github.com/xxxxxxxxxx/notion-website.git" ./deploy.sh
  shell: /usr/bin/bash -e {0}
Deploy directory 'dist/site' does not exist. Aborting.
Error: Process completed with exit code 1.

Hi folks, I haven't had the chance to investigate the root cause yet, but I find that re-running the deploy a few times until it works does the trick. Not ideal, I know, but in my experience it always works after a couple of times.

Not sure if it's relevant to the comments above, but the dist/site folder is named for the "name" variable in site.toml on line 7 of this project, this tripped me up when I tried setting it up. If you're using a custom name the workflow will fail. Loconotion is building the site into dist/{name} so either name your notion site "site" in the site.toml file or modify the script to target dist/{name} instead of dist/site.

Yeah, there is a comment in the site.toml saying not to change that value -- if you do, it does break things! But this flakiness is another issue which I haven't been able to nail down.

It may be possible to append that setting to site.toml during the build process instead of hardcoding it like it is now to avoid that confusion.

Not sure if you guys are still stuck with this. But if you're still looking to fix it, you just need to edit this line to:
docker run \

There seems to be an issue when mounting the volume with docker-compose, so all files generated inside the container are not preserved in the runner directory where the volume was mounted.

Huh. I would never have guessed that might fix it. I’ll give it a try.

Seems to be doing the trick from my limited testing. Nice find, thanks for that @InakiRaba91! I’d love to know what’s going on between docker-compose and docker that would cause the flakiness.