Yay! I can now build my #Jekyll static sites using the #Codeberg #Woodpecker based CI system and push them live on Codeberg pages fully automated!
I made some medical changes to the woodpecker.yml file. It now keeps git commits intact. The first version just ignored everything. https://codeberg.org/jwildeboer/fedigridsource/src/branch/pages/.woodpecker.yml
Now also explained at my blog over on https://jan.wildeboer.net/2022/07/Woodpecker-CI-Jekyll/
@jwildeboer
I like it!
but it's also the reason I'm building my own StaticSiteGenerator™️
@jwildeboer that's the exact same workflow I have with Jekyll and Netlify. I'm totally on board with the idea of moving to Codeberg and Codeberg pages but I just don't have the time right now, plus with Netlify I have a nice way of having forms working on a static website, I should find an alternative for that as well.
@m2m I will put out a blog entry with my working setup using woodpecker and codeberg pages. I hope it'll help you decide :)
@jwildeboer thanks Jan!
@m2m It's out at https://jan.wildeboer.net/2022/07/Woodpecker-CI-Jekyll/ :)
@jwildeboer What's your opinion on Woodpecker? I used it to help automate some stuff for @mondstern's icon pack and I found it very clean and simple to understand, at some points easier than GitHub Actions or GitLab CI. Was quite positively surprised personally.
@SylvieLorxu I had some weirdness with file permissions that I "solved" by chmod 777 inside the container, but besides from that - yep. For my purposes it's good enough, does its job and is nice to work with. Sleek UI, good documentation. Approved :)
@jwildeboer how is everyone managing to use Woodpecker CI, I’ve created a new repo last week, added the yaml file and nothing happened
@dminca @jwildeboer The Woodpecker CI is in beta state. To use it you need to request access first:
https://codeberg.org/Codeberg-CI/request-access
When you have access, visit https://ci.codeberg.org and enable your repo. 🚀
@dminca @jwildeboer have you applied for access to the CI?
After that you'll need to enable Woodpecker once for each Git repo you want to use.
@mforester @jwildeboer oh, haven’t done that, will try that out, thanks!
@dminca @mforester But please be mindful - Codeberg is a non-profit with a lot of volunteer work using limited resources. If you plan to really use their offerings for productive purposes, consider becoming a paying member, if you can. It helps us all to keep things running and getting better ;)
@jwildeboer @mforester makes total sense, no worries, I'll try my best 🫡
@jwildeboer Sounds great, congrats!
We really like the effort of @codeberg making this an enjoyable process, shoutout to the team!
@jwildeboer Jekyll was made to be built locally. NOT on the SERVER! LOCALLY! Guys, build your Jekyll websites locally check, locally, if everything is ok, and then git push the website.
@dani It's 2022 ;) Using a CI pipeline is quite accepted in the Jekyll world. It's also how GitHub and GitLab run their static pages offering. I happily do both. Local build and git push or CI based.
@jwildeboer I also do local build and my GitLab page uses the simple HTML website CI. Which is a waste on GitLab's front. And I have to *wait longer* to see if the online changes have been updated. I consider CI a waste in my opinion. It may only be useful for git in big companies, not on websites. I consider Jekyll and Hugo and similars to not ever need CI. Just makes things more complicated for 2022 ;-)
@dani As long as you are the only person updating the content, that works (and I also use it for a few sites). But when you have a bigger team that edits pages, the CI way makes things easier. Now I don't have to setup a full Jekyll system for every team member. I am happy that both things exist and work.
The .woodpecker.yml file at https://codeberg.org/jwildeboer/fedigridsource/src/branch/pages/.woodpecker.yml shows how I took a rather "robust" approach of using a sledgehammer to get things done, but it works :)