Comment by KronisLV
1 year ago
I initially had a Gogs install, but moved to GitLab because of GitLab CI and some other features. It was a bit too heavyweight in comparison and the updates became difficult to keep up with, so I eventually moved over to Gitea and Drone CI (some might also like the Woodpecker CI project).
Honestly, my eventual next move will be either Forgejo with their Actions https://forgejo.org/docs/next/user/actions/ for CI/CD or maybe going off into the deep end with moving back to Jenkins.
I will never go back to Jenkins. It was my job across several shops over the last decade to keep that thing slogging along and I’m beyond done with it.
For me GitLab CI is a reason to move _away_ from it.
Really? What’d you dislike the most about it? In my experience, the syntax was actually more user friendly than that of GitHub Actions and the file based approach a bit easier to carry across projects than what Jenkins and the likes do.
Drone CI and Woodpecker both felt similar in that regard, at least to me. Though the docs of GitLab CI definitely make me consider it for group projects across an org.
One of my biggest headaches is that the pipeline cache never seemed to work predictably (e.g. not pulling cached data that was available, it uses zip so the permissions are messed up, etc), so I ended up writing my own caching system. It was important for my use case because full runs could take 2 to 3 hours.
Then there is the YAML config which is too convoluted. It took me several attempts to get things right.
What works better, IMO, is to have each CI step as a script or a Make target that can run anywhere (CI or dev PC) and in the CI configuration have a single line in each step that invokes the script.