Our CI workflow literally just invokes a plain old shell script (which is runnable outside CI). We really don't need an overcomplicated professional CI/CD solution.
One of the nice things about switching to Forgejo Actions is that the runner is lightweight, fast, and reliable - none of which I can say for the GitHub Actions runner. But even then, it's still more bloated than we'd ideally like; we don't need all the complexity of the YAML workflow syntax and Node.js-based actions. It'd also be cool for the CI system to integrate with https://codeberg.org/mlugg/robust-jobserver which the Zig compiler and build system will soon start speaking.
So if anything, we're likely to just roll our own runner in the future and making it talk to the Forgejo Actions endpoints.
I mean, … the outages are a big part of it. But those outages also extending to taking out my own hardware (e.g., through bugs like the above consuming resources on my own compute) is just double the pain.
But as a product, it's just bad? Riddled with bugs? In no particular order:
* Artifact APIs will return garbage results during a run. Note that the APIs are separate from the GHA actions for interacting with artifacts, and the latter uses undocumented APIs, presumably b/c the documented APIs are buggy AF.
* needs.… will just return junk data, if you typo.
* Builds of actions are not cached, making them rather slow. Many GH official actions hack around this by pointing the tag/branch (e.g., @v4) at a pre-built artifact.
* The pricing is high, compared to other offerings.
* The interface is just FUBAR: e.g., stdin is a pipe, which will wreak havoc on some commands that change their behavior when piped to. stdout & stderr are pipes, which although GHA ostensibly supports colored output, this basically renders it useless.
* Jobs, steps, actions are conceptual mud. There's a few ideas, like "execute this thing" in there, but its all jumbled up/duplicated. Container settings are configured per-job, so if you want to run some steps in one container, and some in another, but in the same job, you're just going to be left out to dry.
* Secrets are hard to manage, and even harder to not leak.
* The expression language has all sorts of corners, like coerced types and functions with parse-time side-effects!.
> I mean, … the outages are a big part of it. But those outages also extending to taking out my own hardware (e.g., through bugs like the above consuming resources on my own compute) is just double the pain.
Never needed to run my own runner, but yes the outages are annoying.
> Artifact APIs will return garbage results during a run. Note that the APIs are separate from the GHA actions for interacting with artifacts, and the latter uses undocumented APIs, presumably b/c the documented APIs are buggy AF.
Never had an issue either I've only used the GitHub CLI to upload artifacts to releases.
> needs.… will just return junk data, if you typo.
Was not aware, but I have never typod. I'm wondering if a linter such as actionlint would catch this.
> Builds of actions are not cached, making them rather slow. Many GH official actions hack around this by pointing the tag/branch (e.g., @v4) at a pre-built artifact.
Is there not caching actions you can use?
> The pricing is high, compared to other offerings.
Try blacksmith.sh, half the price, faster and unlimited parallelisation etc.
> The interface is just FUBAR: e.g., stdin is a pipe, which will wreak havoc on some commands that change their behavior when piped to. stdout & stderr are pipes, which although GHA ostensibly supports colored output, this basically renders it useless.
I always call out to a task runner, I don't have command inside the workflow so never experienced this.
> Jobs, steps, actions are conceptual mud. There's a few ideas, like "execute this thing" in there, but its all jumbled up/duplicated.
Is it not each job has multiple steps, each step is an action?
> Container settings are configured per-job, so if you want to run some steps in one container, and some in another, but in the same job, you're just going to be left out to dry.
Yeah something you can't do, but never ran into this issue either. Ways around it, such as calling out to a script which does volume mounts and run things in a container using `docker run`. Or just cut up the problem so you don't need to and have multiple jobs or something.
> Secrets are hard to manage, and even harder to not leak.
For a personal account agreed, no way to set a secret for every repository. Recently I have been doing.
```
gh repo list --json name,owner --limit 100 | jq -r '.[] | "\(.owner.login)/\(.name)"' | while read repo; do
if gh secret list --repo "${repo}" --json name | jq -e '.[] | select(.name=="EXAMPLE")' > /dev/null 2>&1; then
gh secret set EXAMPLE --repo "${repo}" --body "${EXAMPLE}"
fi
done
```
> The expression language has all sorts of corners, like coerced types and functions with parse-time side-effects!.
Again I don't really have logic inside a workflow, I call out to Make or a script or something so it has never been an issue.
The people at Zig should use proper CI tools and not something that a big service provider is offering as an afterthought.