#Lazyweb. Has anyone built a #Forgejo Action to run #Jekyll and put the generated files in a directory on a web server? I know about all the GitHub automation using their GitHub pages, but I want to #selfhost and already have the sources of my blog in a git repo on my local forgejo instance. Ideally a solution that runs completely locally, without downloading tons of stuff from docker repos :)
I am truly impressed. Within minutes I got files, advice and support from everywhere around the #fediverse. I now have no more excuses and will have to work hard to get it all up and running and report on teh HOWTO in an upcoming blog post which might already be after I moved my blog to my own server. The Fediverse is full of geeks that are happy to share. And that's not a bad thing in clickbait times! Thank you all :)
@_elena If you need more stories on how the #fediverse brings people together to build new solutions that change the world bit by bit, without Venture Capital, the Open Source Way, here is one. Happy to discuss at FOSDEM in the social web dev room :)
A HUGE thank you to @some_natalie who has built a secure and rather lightweight Jekyll build container that runs rootless without throwing errors! Read her detailed blog entry on that at https://some-natalie.dev/blog/jekyll-in-a-can/ :)
@jwildeboer Like I did it also in the action I send to you. And I didn't need to set the safe directory manually. :D
And regarding if you want to commit something: This was related to the lines where you set the user mail, name and initial branch - if you just clone this isn't needed? 🤔
After long hours of trial and error, and a bit of sleep I have arrived at this for now. An almost universal action that takes a repo with Jekyll sources, builds the static site and commits the static files it to another repo called "web" in a folder with the site name. That repo can be automatically cloned to the web server to update the site! (that final part is what I will work on today). Thanks to @Beowulf for sharing some inspiring sed lines :)
@jwildeboer I understand this. My way was that the CI pushes via rsync to the server.
This makes more sense for me, because the site has a lot of binary files (mostly images), so I don't want to have another big repo which just consumes resources.
But your approach is also interesting. With your way, the CI doesn't need access to the server.