Gitlab New Logo: DevOps Is at the Center of Gitlab | Hacker News Reader

Gitlab New Logo: DevOps Is at the Center of Gitlab

about.gitlab.com

125 points0xedb123 comments

This is why we left Gitlab.

DevOps become center part of Gitlab which we don’t use and need any of those feature. We all need a code storage, code review, issue tracking and the CI/CD. We would pay advance features of those (epics, multiple assignee, etc) but we have to pay super expensive top tier which includes unnecessary DevOps stuff. We left and happy so far.

We are using Kubernetes and custom DevOps tools but don’t want to handle things the way that Gitlab does.

Where did you go instead?

This is happening everywhere. The current industry cycle is one of scope expansion, moving away from the do one thing well paradigm. This will lead to bloated software that do a little bit of everything but not very well, which will trigger the next industry cycle, of doing one thing well paradigm.

I've heard this talked about before, and I believe there's a phrase for it, but I don't remember. Do you happen to know?

Bundling and Unbundling https://stratechery.com/outline/bundling-and-unbundling

Ive started working with Gitlab in last few months for new contract and this was exactly what hit me hard.

Gitlab has too many half-baked features. Ive hit those issues at least a dosen times.

From the top of my head:

- Environment variables dont work with triggers

- MS Teams integration does not support multiple channels

- Masking doesnt work for all variables

- Code AutoDeploy quite often just breaks for no reason..

- Kubernetes integration is super poor

I would prefer to have fewer fearures that actually work well and have good support instead of bunch of stuff you have to sometimes wait years for to be fixed (looking at their issue tracker).

GitLab Product Leader here - we do focus on MVCs and have built a lot of breadth in our product, that's something we are proud of. I do think we do a good job of pivoting and removing features where appropriate. For example we started with a not-secure-enough mechanism for attaching Kubernetes clusters and shifted to the more secure GitLab Agent for Kubernetes[1], deprecating the certificate method. We also started with a "must install Prometheus and Elk on your cluster" Observability solution and are now (after our acquisition of Opstrace) working to make observability on-by-default[2].

[1] https://docs.gitlab.com/ee/user/clusters/agent/ [2] https://about.gitlab.com/direction/monitor/observability/#pr...

Here’s another one of those maddening issues:

https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3376

I’ve had to write a wrapper script around each command that polls the cicd job Id and kills its subprocesses properly if the job is cancelled.

Hello - I am the product manager for GitLab Runner. The SIGTERM-related issues have been quite complex due to the different execution environments in which the Runner can operate. Can you add the details of your use case and workaround to the issue below? We need to take another look at this functionality, given the various reports of inconsistent behavior with long-running processes.

https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27443

CentOS7. I've also asked the SCM team at my employer to get us added as a paying customer who would like this looked at, to help prioritize.

I don't know if you just need to do process groups or walk the subprocess tree or what... but generally, this is a solved problem on Linux for things that manage subprocesses... assuming the processes don't manually do something silly like daemonizing themselves. (That's not my use case.)

Linux should be the easiest case.

edit: What is most frustrating is this issue appears to have been opened ~4 years ago.

Yup. I’ve hit two of those even in my rather casual home use. (The masking and trigger ones)

Still - I do like it overall

I really love GitLab, but I agree it has too many half bake features, and too many features that are wonky.

We use GitLab at work, and I tried hard to push back against the hate for it, but its hard sometimes when GitLab is just WEIRD, especially in simple things like MRs.

What's the distinction between DevOps and CI/CD? I thought CI/CD is DevOps.

CI/CD is part of Devops. It also includes monitoring systems, keeping them up, maintenance, upgrades necessary to keep the software working.

DevOps is a methodology.

Well, I was trying to clarify this statement from OP:

> DevOps become center part of Gitlab which we don’t use and need any of those feature. We all need a code storage, code review, issue tracking and the CI/CD.

It reads to me like this: "We don't use DevOps features in Gitlab, but we use CI/CD pipelines in Gitlab". So it is contradicting. As they responded, CI/CD is a subset of DevOps methodology.

I've used Gitlab and didn't know there were more DevOps tools other than their CI/CD features and runners.

I am still slightly confused.

DevOps is whole set of tools. Gitlab includes features like monitoring, code scanning, Kubernetes integration, docker registry, cloud security and protections. And those are $1188 per year per person. By CI/CD I mean good old Jenkins that runs on a computer in the office that builds iOS Apps and uploads them to Apple AppStore (of course current generation of CI/CD is much better). Gitlab CI/CD and runners were there much before this "Gitlab is the one DevOps platform" saga.

Everyone in our company including HR, marketing, design people were also using Gitlab for task tracking. Therefore we need those fancy issue tracking features for better management. This features are in the tier that $1188/year per person. For the features we don't use is not something that we could afford.

Ah got it, thanks. I wasn’t aware that they’ve built all this stuff.

I thought the OP was maybe referring to Gitlab's "AutoDevOps" features which were introduced a few years ago. From their site:

>"GitLab Auto DevOps is a collection of pre-configured features and integrations that work together to support your software delivery process."

I remember upgrading a Gitlab instance at that time and ended up with an issue that was the result of the AutoDevOps feature set. It seemed that AutoDevops was turned on by default. My issue was easy to resolve but I remember thinking at the time it was rather opinionated.

[1] https://docs.gitlab.com/ee/topics/autodevops/

I think you're mistaken. DevOps is a very specific team allowed to touch the Jenkins box, and is the old branding for what is now SRE which are both just rebranded names for Systems Administration, but with Cloud certifications instead of Cisco and Dell.

I kid. But this is just as much the meme I've encountered as Agile. Some successful company releases a book about something they do that's fundamentally different, and almost instantly enterprises across the globe have a department for that thing with that name. Progress.

SRE jokingly stands for "SysAdmin, Really Expensive"

Real SREs are great. Who wouldn't want a Systems Engineer that codes and can interrogate kernel issues or a Software Engineer capable of writing their own compiler running your operations?

Most companies, even if they hire these people, don't know how to use or listen to them though. What usually happens is they get lumped in with a bunch of Application Operations folks and it sours the idea entirely.

Yeah, this. There's a gulf between people like Brendan Gregg (my go-to example of a "Real SRE") and those I've actually worked with, who anointed themselves with the same title...

As a side-note, is any tech group more keen on title inflation than SREs? In the time I've been a developer / software-engineer I've seen sys admin, DevOps, Cloud Ops, SRE... it's literally the same people.

Your comments really come off as bitter. I think this maybe just says more about the companies you've worked for than anything else. SRE is a methodology and a pretty-well understood methodology at this point.[1] The actual title is less important than the practice. It also goes by different names at different companies, example at FB it's called Production Engineer.

By the way Brendan Gregg is a Performance Engineer not an SRE. I believe that's been his title for close to 20 years, according to the the bio in his books. I don't believe he has ever had the title SRE.

[1] https://cloud.google.com/blog/products/devops-sre/how-to-sta...

> Your comments really come off as bitter.

That wasn't my intent. I have done my share of DevOps, it's not for me. Maybe SRE would be.

> I think this maybe just says more about the companies you've worked for than anything else.

Yes, it does :)

> The actual title is less important than the practice. It also goes by different names at different companies, example at FB it's called Production Engineer.

Absolutely. I'm just saying that I've worked with people titling themselves SRE who aren't doing the stuff of that methodology. When last years DevOps team starts styling themselves as SREs but nothing else changes, then they have definitely missed the point about the methodology being the thing that matters!

It's not just those teams, of course! There are plenty of "fullstack engineers" who wrote a Node function one time.

> By the way Brendan Gregg is a Performance Engineer not an SRE. I believe that's been his title for close to 20 years, according to the the bio in his books. I don't believe he has ever had the title SRE.

This seems to be true, but he's spoken at SRE events on "my SRE work at Netflix".

> As a side-note, is any tech group more keen on title inflation than SREs? In the time I've been a developer / software-engineer I've seen sys admin, DevOps, Cloud Ops, SRE... it's literally the same people.

That's not the fault of people doing the work, that's what the industry is doing to us.

I get increasingly irritated with the myth that 'DevOps' are any different than the sysadmins of 10 years ago.

"But DevOps can code", yes, so could sysadmins, in fact, terraform, ansible, vagrant, saltstack, chef, puppet etc;etc;etc are all made by people who held the title of sysadmin when they were written.

In fact the term "DevOps" was originally from a conference, where the idea was that "we can do systems administration in an agile way" -- NOTHING to do with coding, everything to do with getting developers and sysadmins working closely together in an iterative fashion.

I would personally be very happy being called a sysadmin, but doing so is career suicide, because we as an industry have decided that sysadmins are somehow braindead, and that you really need "SREs" or "DevOps" -- despite the fact that these are the same people.

What gets my goat even more is that people hate on sysadmins because of corporate culture, echos of centralised IT organisations that said no to everything.

But we're doing exactly the same thing with these new titles now. It's a joke.

Yeah this is a really bad direction for gitlab. All of their devops features are terrible. They don’t pay their engineers which is why everything is poorly built.

They should have just focused on being the best vcs. Oh and you get what you pay for. Want to hire a bunch of mediocre engineers? you’ll get a bunch of half baked features

I'm honestly of the opposite opinion. I have used GitLab for 10 years now and have yet to find something as useful as GitLab's CI/CD, and I've tried (not always by choice) a ton of different options.

Mainly it's because I strongly prefer to orient most of my flow around Kubernetes deployments and namespaces tied to git metadata like commit sha or branch name, and thus far, I haven't found a better more interested way of doing so than GitLab.

I agree with this

so what you guys use for the issue, epics, burndownchart and such?

Is it really "center part"? I'll admit there is some unnecessary clutter here and there, but it's easy enough to ignore.

What I don't understand is who these features are for, and who uses them. We use the CI/CD parts, but other than that manage everything through k8s, and I wouldn't dare let GitLab a handle it. And, the whole "one click devops", or what it was called, is even more puzzling.

This is exactly what I am doing for OneDev: https://github.com/theonedev/onedev

Old logo was probably the cleverest rendering of a fox using very few lines. The new logo is a lot less smart, much more standard. Typography is also uninspiring: seems to be using Inter, which is designed to not have any character (pun not intended). Although, to be fair, old logo also had very basic typography.

Wow you're right, old one is impressive, I like it much more, and to me, it even resembles more a fox than the new one. Never thought about how cool those few lines can represent a fox so well and with personality.

Although I admit the concept and spirit of the new change makes sense.

The GitLab logo/mascot is actually a tanuki, a Japanese racoon dog. It symbolizes our values as a smart animal that works in a group to achieve a common goal.

Be honest, you picked it because Tanuki Mario is the best Mario.

...I mean. It doesn't hurt ;)

If the intent of the redesign was to make this more apparent, it also failed in that goal. Old and new both look like a fox.

Old(er) tanuki-like logo for comparison https://gitlab.com/gitlab-com/gitlab-artwork/-/blob/9b07772f...

The intent of the redesign is for the logo to reflect GitLab's place at the center of the DevOps infinity loop.

Why not just do some play on an infinite loop then?

If you check out the post, you can see/read how it is a play on an infinity loop.

Gitlab is at the center of the devops infinity loop huh? News to me

Wait, but the other image file is named fox.png? https://gitlab.com/gitlab-com/gitlab-artwork/-/blob/9b07772f...

That's pretty damn funny.

Not quite. The new one also looks like an evil owl. The old one didn't have a beak.

Your logo is a fox to everyone though, doesn't really matter what the intent was.

No worries, the tanuki and kitsune (fox) are often associated together, as friends or rivals, and have similar folkloric powers and trickster natures. In fact in recent Mario games, when he acquires a tanuki leaf, Luigi transforms into a kitsune.

Agree as a Japanese.

It even is a fox to GitLab as some commenter pointed out, read the file name:

https://gitlab.com/gitlab-com/gitlab-artwork/-/blob/9b07772f...

Not going to lie, I just learned moments ago it wasn't a fox, and honestly looking at tanuki images on google, is still looks more like a fox then it does a tanuki. For me it's the colors throwing everything off.

Ah (totally serious comment, not intending to be insulting or flippant): I always thought it was just a cheeky copy of GitHub's Octocat, because that's how GitLab started too, an open source implementation of GitHub.

Didn't know about this animal, pretty cool.

I believe the Tanuki are much more known in the symbolic sense as mischevious and shapeshifting though no?[1] At least in Japan, where they are native to. There always seems to be one outside of an Izakaya with a flask of sake.[2]

[1] https://www.atlasobscura.com/articles/the-tanuki-japan-s-tri...

[2] https://www.alamy.com/ceramic-statues-of-two-bake-danuki-tan...

Y'all are gonna get really bored of explaining that your dog-like silhouette in distinctively fox colors is a brown raccoon dog.

You might as well have a bright yellow circle to represent the moon.

I was never a fan of the almost like gemstone like angularity of the old one. For me the new one does a good job capturing the spirit and the silhouette while just feeling a bit... nicer. I don't really know how else to put it, it just feels a lot more pleasant to look at.

It's the opposite for me: the old one was playful with that gem/animal in-between, whereas in the new one only the animal part remains. And what's left of the gem-like lines makes it an animal with a mean/aggressive expression on its face.

It's funny how a few simple lines can create so much opinion, I certainly wouldn't want to imply that mine is more correct or something like that. I'm actually surprised myself, because if I was told "much like the old one, but with some curves replacing angularity" I certainly wouldn't have expected that outcome.

If Inter doesn't have character, then which font has character? How does one pick a font that has character?

Any font that doesn't try to be neutral. Consider Cooper Black, or Larken, or even the horrible Lobster. Even with sans-serifs you can be more expressive, for instance Px Grotesk.

https://upload.wikimedia.org/wikipedia/commons/0/0a/Gitlab_l...

I hope that's the old logo you are talking about. Much smarter than these new ones.

Old logo for comparison:

https://gitlab.com/gitlab-com/gitlab-artwork/-/blob/9b07772f...

Bonus:

https://gitlab.com/gitlab-com/gitlab-artwork/-/blob/9b07772f...

I read the article and still don't understand what the new logo is. Did they just round the sides? Is it the start frame of that animation, with the ∞ symbol?

The outside edges are softer and the interior lines are different. The new one has less lines overall and has more of the deep red-orange color.

As much as I love the mustache fox, I struggle with GitLab being at the center of devops. I think source is more powerful to non-devs and hitching everything to devops might present some challenges.

I work with lots of scientists and they don’t care about devops much now and may never need to. But they love GitHub because they collaborate on scripts, manuscripts, demos, small data files, etc. They pay $4/month or whatever and don’t care about devops. There’s lots of people like this.

I think there’s a smaller amount of proper software devs making software that require devops and will pay for devops.

If GitLab is really about devops, then they should be repo agnostic and work with lots of repos. But their core is still source management that they do really well. So their marketing is out of sync with their identity.

I love it.

- I like little quirks in logos like the infinity here.

- It's much more minimal. The old logo had too many unnecessary lines in my opinion.

- I quickly associate the canine appearance and the color orange as a fox so I'm not sure why people are not identifying as one.

- The subtle borders are chef's kiss.

The old logo had a fun little animation when you hovered over it which took advantage of all the lines, seems they did away with it :(

>DevOps Is at the Center of Gitlab

Yeah, just had a call with them and they confirmed that for only VCS its not feasible to use their platform.

What are people migrating to? I am looking at bitbucket again I guess.

What do you mean? Do they just not offer a plan that is cost effective for a source control only use case? I currently use their source control and CI features, and that's it. No issues.

There is free tier that will have limit of 5 users in June.

The Free tier of GitLab SaaS will have a limit of 5 users per namespace beginning June 22, 2022

https://about.gitlab.com/blog/2022/03/24/efficient-free-tier...

Self-managed GitLab won't have this user limit. You can run GitLab EE without a license (which is the Free tier then), or GitLab CE (only open source components), on a cloud VM via Omnibus package installation or in Docker containers, in a Kubernetes cluster, or on a Raspberry Pi.

https://about.gitlab.com/install/

I work at GitLab, but curious what your use case is for just VCS? I assume your company has other solutions for the software lifecycle that you are happy with?

Depending on the size of your org, If it's small GitLab CE is free and can readily handle VCS no problem, you won't have a support contract though.

I am in charge of reporting, business intelligence and DE. We use VCS to have all our SQL transformations stored there.

Like that all the business users interested can see whats happening in background and we have things version controlled.

For rest of the features we don't have use case and our "proper IT" is using github instead, but there you have to pay per seat in org. as I heard

explaining it now, for business users we would achieve the same if they had access to sharepoint folder with the code + syntax highlighting.

But I also believe its beneficial to educate the user about VCS as side objective.

If the business users never need to write, just read, then you could set the projects to public (if your instance is in a private network) and then people can have vis, and you don't need seats for those who aren't writing. I think both products support this as an option.

We ran into the same issue using dbt. Unfortunately it is just not cost-effective to pay for full GitLab licenses for BI users that occasionally tweak SQL queries and don’t leverage any other GitLab features.

> use case is for just VCS

Ye, just VCS. Nothing else.

Why do you ask? I don’t build my code/text. Hell I don’t even want to ever compile it. I like making code/text changes and play push and pull and sometimes merge. And reviews, don’t forget them. I’ve some peers who also like that. Maybe we do it just for the kicks. Maybe it pays as well. We want to do all of this on an excellent git platform with a fantastic intuitive UI; and we definitely want to pay for it. Just give us a solid VCS. What about that?

Depending on if your arch is supported, pipelines on bitbucket is pretty cool.

I would probably look back at github (or gitea if self-hosted and you're looking for simplicity), bitbucket is a pile of features that almost work, but you're constantly reminded that you've seem better.

Commit control after PR decline/merge is one of them for me.

I have been following OneDev and seems like it is going to be a good contender.

https://github.com/theonedev/onedev

I've been seeing codeberg.org more and more recently

Bibucket's code review tools are really bad.

As usual for Atlassian products, every click takes 1-2 seconds.

Finding comments requires manually scrolling. There is a filter function, but it takes some time to load. And even then, there's no way to sort comments chronologically. As a result, we would be constantly missing responses if it wasn't for the email notifications.

If a correction is made through force-push, you'll have no idea what was changed compared to the replaced commit.

The phone interface is unusable. On iPad, scrolling unintentionally adds comments.

There is a VSCode Plugin which is slightly better, but even there we frequently miss comments or changes.

Brought down the repo at an airline when I included an emoji in a commit message.

Gitolite is open source and really easy to self host if you only need VCS.

I haven’t used it but I think sr.ht might match your needs.

If you’re not happy with Gitlab, the last thing you want is anything by Atlassian.

SourceHut

I like that it feels more organic (?) and friendly but still recognizable because it is close enough to the previous one.

Friendly ... for me the new logo has anger in it. The old one was without emotion.

First time I'm hearing the "DevOps infinity logo", it seems that everything uses a variation of this: Meta, VS Code...

It's shitty brand design is what it is.

Infinity is the new hexagon.

Does this mean I can ewrite a web app, put the source on GitLab and have GitLab run the web app (ideally with very minimal hassle)?

If not, what does it mean? What is Gitlab letting me do now than (a) it didn't do before (b) Github doesn't do?

It means that a big part Gitlab's offering is now things like CI, whereas originally it was just code hosting.

They haven't sold them selves as 'just code hosting' for some time. I almost wish they did. They've negleted basic stuff yet their marketing sells them as an all-in-one solution. A thousand dollars per seat per year (no fractions!) for the WHOLE organization just for nested Epics? No thanks. This 2 year old thread just keeps on giving:

https://gitlab.com/gitlab-org/gitlab/-/issues/213185

I'd join many participants in advising anyone to think very carefully before adopting GitLab.

Would you be able to list some of the negative developments you expect from GitLab going forward? For example, I know they are reducing support for Free Tier on their managed instance (https://news.ycombinator.com/item?id=30791162). Is that the kind of thing you're talking about?

What would you recommend instead? Gitea?

I should say that I respect and admire GitLab's pursuit of financial sustainability and not selling themselves too cheap. But the resulting culture, combined with the actual product experience, is offputting.

The issue tracking and labelling system is fine for what it is, but not good enough for planning projects. The Epics and Milestones functionality appears thrown together and isn't useful for much (we tried). Missing features such as persistent links to milestones (links are essentially a text string), lack of workflows ("You can do anything! Just ... use labels"), Milestones lack a change history, lack of nested Epics.

We want to be able to use confidential issues every now and again, which mean that everyone in the org needs a seat license to contribute or even view. If you want nested Epics you have to jump from $240 /seat/year to $1200 /seat/year for every single seat (hence the above linked issue).

Fundamentally they are trying to be the "everything" platform, and their sales material suggets that you can drop subscriptions to all kinds of competitors. Our experience was that the features weren't quite good enough.

I don't necessarily expect things to get worse. I just find that the tools aren't quite good enough to justify the sales talk, and seeing them expand the breadth of feature set without improving core stuff is disappointing.

We're staying with GitLab for code and dev team, because we're already there and we've built CI pipelines etc. But moving to Jira for issue tracking and planning, and so far it's much nicer.

EDIT: Just noticed that they closed the issue [0] with a glib "opportunities to help customers derive more value from GitLab".

[0] https://gitlab.com/gitlab-org/gitlab/-/issues/213185

> But moving to Jira for issue tracking and planning, and so far it's much nicer.

Wow, Jira being better is really damning. FWIW, there's a lot of competitors to Jira these days, and most of them are much better. We're using Shortcut, and it's been excellent.

Yeah we went into it with eyes open. I know "everyone hates Jira".

We did evaluate Shortcut (formerly Clubhouse) and I did talk to a sales engineer.

We weren't able to make our issues open to the public, which was a serious blocker.

It wasn't clear how we would differentiate between user stories, bug tracking, epics, planned work, etc. And how to handle and track support and operational issues.

The response in the org (we're not all devs) has been almost universally positive, and very favourable compared to our GitLab issue-tracking experience.

Which is unfortunate, because outside of gitlab.com, I've found gitlabs CI offering to be more unpleasant than any of the competition in terms of "DevOps" implementation, scalability and automation.

I'm amazed that more people aren't vocal about this. When I was using Gitlab (last year) the pipelines seemed unnecessarily complicated with knowledge of the underlying implementation details sometimes being required to get anything done. Almost every week we would hit some edge case to be presented with a several year old thread on Gitlab where loads of other people have the same problem and it hasn't been addressed yet.

A year or two ago the industry decided everything had to be 'a platform'. This is them saying "we too will chase industry trends for cash. we have a platform!!! bring us your money". The branding/logo thing... I guess is to reinforce to potential customers that they do more than host code, I dunno. Nobody understands what DevOps means so I'm not sure why they'd lean into that.

GitLab team member here.

You may want to check out (and sign up as a beta tester) for Cloud Seed, an open-source program led by GitLab Incubation Engineering in collaboration with Google Cloud: https://hello.cloudseed.app/

According to that URL:

> Deploying web applications from GitLab to major cloud providers should be trivial.

Yes, that's what I want! I find it easy to develop web apps in Python, but a PITA to deploy them.

You can get gitlab cicd to build a docker image based on your python code that you can push to whatever cloud thing you like

Not exactly gitlab but a cloud provider via https://docs.gitlab.com/ee/topics/autodevops/index.html - bonus is you get feature branch hosting if you want too. I've used it and it worked well, even wrote an Elixir/Pheonix custom buildpack (but most common frameworks supported)

GitLab team member here.

> Does this mean I can ewrite a web app, put the source on GitLab and have GitLab run the web app (ideally with very minimal hassle)?

Cloud Seed aims to make this easier, deploying the web application with minimal effort to your preferred cloud. More details in https://docs.gitlab.com/ee/cloud_seed/ and https://hello.cloudseed.app/ - it is a joint project from Google Cloud and GitLab.

In case you run your web app in a containerized stack, and prefer to deploy to Kubernetes, the integration with the Agent for Kubernetes has been greatly improved: https://docs.gitlab.com/ee/user/clusters/agent/

If you are looking to host static web apps (e.g. Hugo, etc.), GitLab Pages can help. More ideas in this blog post to choose a static site generator (SSG): https://about.gitlab.com/blog/2022/04/18/comparing-static-si...

> If not, what does it mean? What is Gitlab letting me do now than (a) it didn't do before (b) Github doesn't do?

Depending on which version you are at, new releases add features every month on the 22nd. GitLab 14.10 https://about.gitlab.com/releases/2022/04/22/gitlab-14-10-re... added the GitLab Runner Operator for Kubernetes for example. That's an integration after the create (SCM) and verify (CI) stage, ensuring that cloud native deployments deploy applications, and maintenance levels follow best practices. There are more stages in the DevOps lifecycle, such as package and release or protect and secure.

Observability for deployed applications, and ensuring that performance regressions do not reach production is also a very hot topic imho (shameless plug: join my talk at KubeCon EU to chat more https://kccnceu2022.sched.com/event/yttd?iframe=no :))

With regards what you can do now - I've written a blog post about my favourite hacks in GitLab a while ago, maybe there are some features or workflows that are useful for your environment: https://about.gitlab.com/blog/2021/10/19/top-10-gitlab-hacks...

That said, GitLab 15.0 is around the corner, coming May 22. https://about.gitlab.com/upcoming-releases/ I'm personally most excited about the Podman support for GitLab runner, helping with containerized CI/CD infrastructure as alternative to Docker as executor.

The GitLab direction handbook provides more insights for future plans: https://about.gitlab.com/direction/ Recommend diving into the stages and review based on your requirements, or potential new ideas and use cases. If you miss anything, please open feature proposals to collaborate: https://gitlab.com/gitlab-org/gitlab/-/issues Thanks :)

> In case you run your web app in a containerized stack, and prefer to deploy to Kubernetes, the integration with the Agent for Kubernetes has been greatly improved: https://docs.gitlab.com/ee/user/clusters/agent/

I've never used Kubernetes, but have seen it described as a PITA to set up and use, which is why I'm not keen on it.

Ohhhhhhhh it just dawned on me that when GitLab says "DevOps" – they aren't confusingly saying "terraform, etc" type DevOps (Developer/Operations tasks combined), which is actually what everyone else means.

I think they mean "the operations around running a development shop" ... like "Developer Operations."

Silly, but makes so much of their random language about DevOps actually make sense now.

Well it does have a terraform registry built in by default so jury is still out on which one is meant

You literally couldn’t pay me to use gitlabs devops tools. They are very poorly built without seemingly any understanding of good practices in the larger ecosystem.

Just be a really great vcs, that would make devs love you. Right now they are playing the atlassian game of checking feature boxes which are all built poorly.

Before I clicked I already knew it would incorporate the horizontal lemniscate... that seems to have become synonymous with devops.

I'm extremely tired of that symbol at this point, I mean there's 4 of those images when I google for "devops" and nothing else: https://i.imgur.com/pr9d8KH.png

If the horizontal lemniscate is synonymous with DevOps that's exactly what I would expect when searching for "devops". Do you think it's a bad representation of what DevOps is? Otherwise I don't understand what you're tired of.

I think that you can apply the lemniscate to basically anything.

Feels lazy to keep reciting it as if it’s novel or unique.

Is this a new Firefox service? Hey, I can create a real corporate identity for you. After a serious research and thousands of variants. It is cheap: only 200k USD.:)

Now, a question: Why established IT companies rarely understand the importance of the words "Identity" and "Brand Differentiation"?

Ah gitlab. I tried two whole days to do something, I assumed CI was created for: compiling a binary artifact, and distributing it with some sort of URL where I can always get the latest version.

Guess what: it cannot be done nicely without going back and forth with the API uploading that artifact via curl (?!) from Gitlab to Gitlab etc.

If even such a fundamental thing is not straightforward, I don't want to know about complicated things..

https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#a...

    make_tarball:
      script:
      - tar cf dist/tarball.tar.gz project/

      artifacts:
        paths:
        - dist/tarball.tar.gz

    https://gitlab.com/api/v4/projects/username%2Fproject/jobs/artifacts/master/raw/dist/tarball.tar.gz?job=make_tarball

This is a Borland -> Inprise tier shift in marketing.

Subtle change. I enjoy the concept and execution.

Anyone have experience with gitlab's Auto-DevOps stuff? Haven't really had an opportunity to use it (I do use their CI product) but am curious how people who've tried it find it.

I just don't understand what it is even supposed to be. We have what should be the simplest pipeline ever with dotnet. It could be three lines, dotnet test, dotnet publish, then create the docker image.

But it doesn't seem to support dotnet.

Oh, so maybe it can automatically rebuild our docker images? No, that's not what they mean by auto either.

How about tests? No, they only support JUnit format with a terrible ui. And no history.

Coverage or code quality? No, not really.

Github on the other hand has one click pipeline actions.

It's scary having the CI/CD magically figure out what to do for you purely based on the files in your repo. I bet it would save a lot of time if you were actually able to use it for everything in your company. I'd rather write my own CI, which I do in Gitlab CI.

Agreed. So much that the git part doesn’t seem to remain a priority anymore.

I use Github for some of our public repos and it feels so much better than Gitlab. It was surprising to see they’ve improved.

So, rounded corners, huh?

My gripe with gitlab is it's absolutely massive, compare to gitea and you miss a few features but you gain the ability for a lowly sysadmin to manage it.

wish I could have cheap gitlab

I mean I don't need all the ci cd but the project management like burn down chart Weighting and such

People hate change, and this one is very incremental. Without the press release I doubt I would've noticed.

Reply on news.ycombinator.com