6 ms·

At this point, just pause with Github Actions and compare it to how GiLab handles CI. Much more intuitive, taking shell scripts and other script commands nativ

At this point, just pause with Github Actions and compare it to how GiLab handles CI. Much more intuitive, taking shell scripts and other script commands natively and not devolving into a mess of obfuscated typescript wrapped actions that need a shit ton of dependencies.

danillonunes 2y ago
But you can do the same with GitHub, right? Although most docs and articles focus on 3rd party actions, nothing stops you to just run everything in your own shell script.
- lolinder 2y ago
  Yes, you can, and we do at my current job. Much of the time it's not even really the harder approach compared to using someone else's action, it's just that the existence of third party actions makes people feel obliged to use them because they wouldn't want to be accused of Not Invented Here Syndrome.
arccy 2y ago
if anything, gitlab's ci seems even worse...
Aeolun 2y ago
The problem with Gitlab CI is that now you need to use Gitlab. I’m not even sure when I started feeling like that was a bad thing. Probably when they started glueing a bunch of badly executed security crud onto the main product.
- Espressosaurus 2y ago
  GitLab can't even show you more than a few lines of context without requiring you to manually click a bunch of times. Forget the CI functionality, for pull requests it's absolutely awful.
- plagiarist 2y ago
  I decided it was a bad thing when they sent password reset emails to addresses given by unauthenticated users. Not that I ever used them. But now it is a hard no, permanently. They have since had other also severe CVEs. That has made me feel pretty confident in my decision.
  - reshlo 2y ago
    If password reset emails shouldn’t be sent to unauthenticated users, how would users reset their passwords?
    - dijit 2y ago
      there was a pretty bad bug (though I think it was a rails footgun)- that allowed you to append an arbitrary email to the reset request. The only difficult part for the attacker was finding an email address that was used by the target; though thats hsually the same as you use for git commits; and gitlab “handily” has an email address assigned to each user-id incrementing from 1; Usually low numbers are admins, so, a pretty big attack vector when combined.
- lolinder 2y ago
  The earliest warning sign I had for GitLab was when they eliminated any pricing tier below their equivalent of GitHub's Enterprise tier. That day, they very effectively communicated that they had decided they were only interested in serving Enterprises, and everything about their product has predictably degraded ever since, to the point where now they're now branding themselves "the most comprehensive AI-powered DevSecOps Platform" with a straight face.

danillonunes 2y ago

But you can do the same with GitHub, right? Although most docs and articles focus on 3rd party actions, nothing stops you to just run everything in your own shell script.

lolinder 2y ago
Yes, you can, and we do at my current job. Much of the time it's not even really the harder approach compared to using someone else's action, it's just that the existence of third party actions makes people feel obliged to use them because they wouldn't want to be accused of Not Invented Here Syndrome.

arccy 2y ago

if anything, gitlab's ci seems even worse...

Aeolun 2y ago

The problem with Gitlab CI is that now you need to use Gitlab. I’m not even sure when I started feeling like that was a bad thing. Probably when they started glueing a bunch of badly executed security crud onto the main product.

Espressosaurus 2y ago
GitLab can't even show you more than a few lines of context without requiring you to manually click a bunch of times. Forget the CI functionality, for pull requests it's absolutely awful.
plagiarist 2y ago
I decided it was a bad thing when they sent password reset emails to addresses given by unauthenticated users. Not that I ever used them. But now it is a hard no, permanently. They have since had other also severe CVEs. That has made me feel pretty confident in my decision.
- reshlo 2y ago
  If password reset emails shouldn’t be sent to unauthenticated users, how would users reset their passwords?
  - dijit 2y ago
    there was a pretty bad bug (though I think it was a rails footgun)- that allowed you to append an arbitrary email to the reset request. The only difficult part for the attacker was finding an email address that was used by the target; though thats hsually the same as you use for git commits; and gitlab “handily” has an email address assigned to each user-id incrementing from 1; Usually low numbers are admins, so, a pretty big attack vector when combined.
lolinder 2y ago
The earliest warning sign I had for GitLab was when they eliminated any pricing tier below their equivalent of GitHub's Enterprise tier. That day, they very effectively communicated that they had decided they were only interested in serving Enterprises, and everything about their product has predictably degraded ever since, to the point where now they're now branding themselves "the most comprehensive AI-powered DevSecOps Platform" with a straight face.