Been playing around with @forgejo actions the last few days, because that seems to open up some possibilities (running our own runners, etc), but dear Cthulhu the workflow syntax is half baked compared to Woodpecker/Drone.
That wasn't great, but it was better than GitLab's syntax, which was way worse than Travis.
Makes me sad once more that Travis got taken over by some years back and made life so much worse for the fine folk I met from there.
@jens@forgejo debugging and testing is actually the one thing Forgejo Actions is better at than any other CI I know. It is still way more complicated than it should be, but it is possible.
GitLab? There is no notion of actions or plugin.
Woodpecker? The plugins are not tested (the syntax is sometime tested, but the behavior? never). Would it be possible? Yes, but noone does it because it is too complicated.
@jens@forgejo although I got used to it, the syntax is an acquired taste. I did not find it worse or better than GitLab Jenkins, Travis or Woodpecker CI. For all of them, during the initial learning curve, I kept asking myself: why?
Why invent a declarative syntax for something that is obviously a program?
@earlwarren@forgejo It's a mixture of a program and metadata that filters when to run the program. Part of the issue is reusability; people might want to run the same code for different events. And part is avoiding having to spin up a potentially large docker container only to bow out immediately because the conditions aren't right.
It makes sense, on the whole. What I'm not happy with are a bunch of things...
@earlwarren@forgejo One of the more obvious ones is that, as we discussed elsewhere, things that are typed in YAML aren't typed everywhere, it seems. It's jarring when you're writing YAML files.
Another less obvious one is that YAML is powerful; it lets you declare fields for later use by reference. But that kind of implies that you need to write down some values that have no specific meaning by themselves.
The ACT, etc linters aren't very happy with top level keys they don't know, though.
@earlwarren@forgejo So you end up debugging around undocumented non-standard interpretations of the input format, and that's really rather bad.
My latest niggle is more forgejo specific; I've given in and made actions with Dockerfiles for re-use. But when I update the entrypoint script, the runners don't recompile the image, and keep running an old version.
It makes sense to a degree, but it means I can't really do what I'm doing, which is add a workflow to their repo to run the action "./".
@jens@forgejo that's a good summary of what's not good with Forgejo Action.
Another way to look at it is that it is not properly tested and lacks documentation. There are a zillion ways to do something wrong.
My approach is to add tests and documentation whenever I find something that works. So that I can eventually answer questions by pointing to examples and documentation.
Given the complexity of the codebase, having a clean implementation seems really difficult.
I feel that with ACT as the basis for GH and Gitea / Forgejo, that's likely turning into an industry standard, but I can't say I'm looking forward to another iteration of something that is essentially simple.
Plus, you can already feel the lock in that comes before the bait and switch.
@jens oh I'm going to have to setup this kind of Devops stuff soon!
Whats your advice for a stable, straightforward, full-featured, and self-hosted git server that I could set up a build process that runs and deploys a simple static site generator build, probably with Hugo?
Add comment