Yay! I can now build my static sites using the based CI system and push them live on Codeberg pages fully automated!

The .woodpecker.yml file at shows how I took a rather "robust" approach of using a sledgehammer to get things done, but it works :)

Feel free to send me pull requests and make it a bit more elegant :)

This is now a really nice workflow. I can work on my pages from my laptop with a local Jekyll setup, use jekyll serve to check everything and when done I just commit to codeberg and wait a few seconds - everything updated :)

I made some medical changes to the woodpecker.yml file. It now keeps git commits intact. The first version just ignored everything.

I like it! :ameowbongo:

:blobcatgooglytrash:​ 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 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:
When you have access, visit 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.

@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 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.

Sign in to participate in the conversation

Mastodon instance for people with Wildeboer as their last name