Comment by dijit
16 hours ago
Weirdly, I also have fond memories of Trac despite absolutely despising it at the time for “doing too much and excelling at nothing as a result”.
I guess that award goes to Gitlab now, which I will probably also remember fondly.
I like Gitlab fine by ignoring pretty much everything it does other than host the source code and let me view READMEs in the browser (and for work, also merge requests). In general the more I have to use anything other than those, the more frustrated I get, which was also how I felt about Github in the past. I'm not sure I've ever had a non-frustrating experience when trying to set up a CI pipeline on any platform, so I guess Gitlab's CI isn't any better or worse than others in that regard. There are an awful lot of tabs on the left any time I look for something through those menus though, most of which I don't know what they do and I would probably not be happy to have to learn.
> I'm not sure I've ever had a non-frustrating experience when trying to set up a CI pipeline on any platform, so I guess Gitlab's CI isn't any better or worse than others in that regard.
Honestly, Gitlab's CI is one of its killer features.
I really enjoy Gitlab CI.
But, nearly everything else (kubernetes management, AST, AI "DUO", work items, milestones, snippets, workspaces, "operations", "security dashboards", "value stream managements", "service desk") - ugh, awful.
I guess some of the artifact repository stuff is nice, but like; their terraform repository is probably the worst of all choices, all the downsides of the HTTP state backend and no upside..
It's so hit and miss; but! the CI is actually good..
I don't hate using Gitlab CI once it's set up; I just hate "put shell scripts in YAML to define how this should work". The least annoying experiences I've had with them are when every entry is literally just a single line that invokes an external script; shell scripting is already annoying enough without having to also spend the time to understand a YAML schema for what order they get invoked in and what environmental variables are in scope (not to mention what the implicit inputs are; a few months ago I tried to add a task to run some check on the commit message for an MR, and I found that even on repositories where the merge commit option is disabled in favor of squashing or fast-forwarding, the top commit message is still a merge commit).
1 reply →
> I guess that award goes to Gitlab now
Painfully true - I remember a company I was at replacing GitHub and a bunch of other tools with GitLab because it was better to pay for one tool that does it all. Kind of.