Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gitlab New Logo: DevOps Is at the Center of Gitlab

about.gitlab.com

Post reply on HN
Print view View original

121–130 of 131 posts

Re: Gitlab New Logo: DevOps Is at the Center of Gitlab

#121

Post by thinkpad13 »

sercand wrote: post #30

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 d…

I agree with this

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

Re: Gitlab New Logo: DevOps Is at the Center of Gitlab

#122

Post by atoav »

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..

Re: Gitlab New Logo: DevOps Is at the Center of Gitlab

#123

Post by otterlicious »

atoav wrote: post #122

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 abo…

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

Re: Gitlab New Logo: DevOps Is at the Center of Gitlab

#124

Post by okamiueru »

sercand wrote: post #30

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 d…

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.

Re: Gitlab New Logo: DevOps Is at the Center of Gitlab

#125

Post by vosper »

bogomipz wrote: post #119
vosper wrote: post #105

Earlier quoted context omitted.

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…

> 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".

Re: Gitlab New Logo: DevOps Is at the Center of Gitlab

#126

Post by robinshen »

sercand wrote: post #30

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 d…

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

Re: Gitlab New Logo: DevOps Is at the Center of Gitlab

#127

Post by deastman »

rrauenza wrote: post #108
kjohnstonGTLB wrote: post #94

Earlier quoted context omitted.

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 w…

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

Re: Gitlab New Logo: DevOps Is at the Center of Gitlab

#128

Post by dijit »

vosper wrote: post #105
kodah wrote: post #87

Earlier quoted context omitted.

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.

> 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.

Re: Gitlab New Logo: DevOps Is at the Center of Gitlab

#129

Post by rrauenza »

deastman wrote: post #127
rrauenza wrote: post #108

Earlier quoted context omitted.

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/gi…

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.

Re: Gitlab New Logo: DevOps Is at the Center of Gitlab

#130

Post by apple4ever »

pojzon wrote: post #93
100011_100001 wrote: post #42

Earlier quoted context omitted.

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.

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.…

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.

Post reply on HN