Last time I tried Github Actions I was shocked at how bad it was. Somehow over and under documented at the same time, and overly dependent on third party repos to accomplish the most basic tasks. I gave up and used CircleCI.
When I started using it it was free private repos and CI minutes.
Whilst GH has duplicated these features very recently, they are still things that are at the core of gitlabs offering, so are generally higher quality and better supported.
Gitlab is also open source, which lets me mirror their repo locally in case they die or remove a feature I use.
Oh, and gitlab isn't systematically racist, which is always a personal ethical win.
Shout out to sourcehut as a possible next cool thing - currently in public alpha
> Oh, and gitlab isn't systematically racist, which is always a personal ethical win.
Wait, what? How is GitHub "systematically racist"?
> Shout out to sourcehut as a possible next cool thing - currently in public alpha
Sourcehut seems like a niche product for a niche audience. That's not a criticism – if anything, that's a compliment because too often people with niche needs or preferences are left out in the cold, but I don't think it'll be anywhere near the "next GitHub".
They're probably referring to a code-of-conduct document which has been attributed to GitHub, although I believe the document is (was?) actually maintained by the TODO Group, of which GitHub is a member.
IMHO the gitlab CI service makes a lot more sense though, github has this weird concept of "Actions", and running CI/CD/... is some "shortcut" that was added as an afterthought because nobody could figure out how github actions are supposed to work for something simple as "please just run this script after each push".
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!
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.
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...
I mean, I get the "new" Microsoft. And I get that this is mostly a street-cred move by them, and they'll try to not mess it up by interfering with it. But still. That's now. What happens when the next shake-up comes and there's a push by the accountants to make money off everything, that's the important bit.
It's like Atlassian taking over Trello. They'll mess it up, it's just a matter of when not if.
Just to clarify here. It's only been owned by Microsoft for about a year now.
Before that they were their own company. And as far as I know, the source was never OSS to begin with. Microsoft didn't swoop in and lock it down. It was already like that.
In case anybody wondered if Github was closed-source because of Microsoft.
