211–220 of 267 posts
Earlier quoted context omitted.
I have also used Travis. Ditto. Github Actions is actually one of the better CI options out there, even if on an absolute scale it is still pretty bad. As far as I can tell nobody has made a CI system that is actually good .
GitLab CI is pretty close to being actually good. Certainly less brittle than GitHub Actions from the looks of it...
A lot of the actions people tend to use are just unnecessary. They're simple wrappers around real tools. In those cases, use mise-en-place. It's a single action that installs all relevant tools (and keeps your local dev env in check), and it supports lock files.
GitHub actions has some rough edges around caching, but all the packaging is totally unimportant and best avoided.
Earlier quoted context omitted.
Yes, their oidc setup was probably their last good feature back when they were actually delivering features back in 2020ish. Everyone else copied it within a few months though.
Who is everyone? As with pretty much every GitHub feature, GitLab had them beat by a few years.
Earlier quoted context omitted.
Who is everyone? As with pretty much every GitHub feature, GitLab had them beat by a few years.
Maybe in some other form, but the current style of injecting an oidc token was definitely in github actions first. Here is the gitlab issue tracking the final bit of it's implementation directly mentioning github: https://gitlab.com/gitlab-org/gitlab/-/issues/356986
Earlier quoted context omitted.
I don’t make the purchasing decision for my employer, but I certainly have to deal with their fallout, so I’ll keep complaining if that’s okay with you.
If you are not part of the solution, then you are part of the problem.
So I’m part of the problem? Me specifically?
What’s more, GitHub has basically stopped maintaining their own actions, pushing people to sketchy forks to do basic things. Their entire ecosystem is basically held up with duct tape and gets very little investment.
I never used any actions and never understood why would I need to. I just wrote bash script to build my project and that's about it. This modern tendency to add dependencies for trivial things baffles me. You don't need "action" to do `git clone`.
I committed the project I maintain to GitHub Actions when Actions first came out, and I'm really starting to regret it. The main problem, which this article touches, is that GHA adds a whole new dimension of dependency treadmill. You now have a new set of upstreams that you have to keep up to date along with your actual deployment upstreams.
I've not understood the propensity for using yaml for CI pipelines and workflows in general. A decent programming language would be a big improvement. Why not just build the workflows themselves as docker images? I guess running other docker images in the workflow would then become a problem.
> I've not understood the propensity for using yaml for CI pipelines and workflows in general. A decent programming language would be a big improvement. Because it's clear to write and read. You don't want your CI/CD logic to end up being spaghetti because a super ninja engineer decided they can do crazy stuff just because they can. Same reason why it's a bad idea to create your infrastructure directly in a programmi…
YAML is fine for data, but inevitably stuff like workflows end up tacking on imperative features to a declarative language.
Earlier quoted context omitted.
- Using the commit SHA of a released action version is the safest for stability and security. This is not true for stability in practice: the action often depends on a specific Node version (which may not be supported by the runner at some point) and/or a versioned API that becomes unsupported. I've had better luck with @main.
Depends what you mean by stability. The post is complaining about the lack of lockfiles, and the problem you describe would also be an issue with lockfiles.