[jacobparker]

It's really hard to understand what you're trying to say here. I use actions a lot. There is no distinction between actions and CI/CD here. The context of this blog post is a set of features that were added to actions (during the beta!) to better support CI/CD workflows. There is no CI/CD "shortcut", like you say, bolted on to actions.

The alpha was rougher (and completely different) but that's why it was called an alpha!

[flohofwoe]

I guess what I wanted to say is that gitlab's CI/CD solution makes more sense because it was specifically designed for CI/CD, while I seriously didn't understand what problems github actions were intended to solve when the beta started. Only roughly a year later a simple CI/CD system was bolted on as an afterthought. This isn't a showstopper, but it makes the overall system needlessly complex and hard to understand if all you need is a CI/CD solution.

When I worked with gitlab CI, I've read through the documentation, understood immediately how it works, and had a pipeline up and running half an hour later.

When github actions was started, I approached it with the same mindset as I approached (for instance) travis.ci, AppVeyor or gitlab CI. But after reading through the github action documentation I had no idea how to make this work for a CI/CD workflow, so I ignored it and continued using travis.ci and AppVeyor for my github projects. Only roughly a year later the above mentioned CI/CD support was added to github actions, which finally made it useable in the same way as all the other CI services.

So my suspicion is: github actions was going to be a new "revolutionary" thing with a much wider scope than existing CI/CD solution. But most people didn't understand such a "visionary" concept, and instead just wanted a simple CI/CD service similar to all the 3rd party solutions that already existed, only better integrated with the rest of github.

And that's why I think that gitlab's integrated CI/CD service makes a lot more sense. It was much more focused on the developer's needs from the beginning.

[jacobparker]

Thanks for the reply. What do you mean by a CI/CD system?

I'm not sure what you think was "bolted on" to actions, could you be specific? Features have been added (during the beta and since) but I can't think of anything that could really be described as "bolted on". "bolted on" to me implies some kind of disharmony with other features, weird quirks etc.

> I seriously didn't understand what problems github actions were intended to solve

You can run arbitrary code in response to any GitHub repository event, and also cron jobs and external triggers (a GitHub app can POST to a specific API to trigger those style of workflows).

The code runs with access to GitHub APIs for your repo (it can clone it, leave comments, create new PRs, whatever), and in any event that is associated with a PR a check status gets added to the PR.

This is a pretty general-purpose tool and I think it's easy to imagine the kind of problems people would use it to solve...

> my suspicion is [...]

Honestly it sounds like you're not really familiar with it and have some strongly negative opinions. I'd recommend either giving it another look and putting aside your feelings or working on a more substantive critique...