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

Gitlab S-1

sec.gov

Post reply on HN
Print view View original

141–150 of 295 posts

Re: Gitlab S-1

#141

Post by kickopotomus »

secondaryacct wrote: post #64

I m in one of the companies they quoted as case study. The lies are so horrible I hesitate to do something: they fucked us completely replacing a wonderful github/teamcity combo, it crashes all the time, features are so amateurish (vs teamcity especially) that we're struggling just to do basic things. I dont know what to do, but public investors should stay away: the product is not ready for people to pay for it. It'…

> it crashes all the time, features are so amateurish (vs teamcity especially) that we're struggling just to do basic things.

Do you have an on-prem instance? What sort of features does teamcity have that are not there in Gitlab CI?

Teams in my org are currently switching from Gerrit/Jenkins combos to Gitlab and I have been pretty pleased so far. I do wish there was a nicer way to experiment with different CI configurations from within the browser to prevent a bunch of pointless commits messing with your config YAML; but, otherwise I have been pretty happy with the flexibility.

Re: Gitlab S-1

#142

Post by NovemberWhiskey »

amelius wrote: post #131
stefan_ wrote: post #126

Earlier quoted context omitted.

Half sarcastic, half serious? I think the prevailing theory is that yes these companies are spending tons of money to get a little bit of money, but it's a one time per customer expense and that customer will still be there for many more quarters, paying monthly dues.

Sounds a lot like: https://en.wikipedia.org/wiki/Predatory_pricing And is illegal in some jurisdictions and frowned upon in others.

No? The point is just that revenue for subscription models recurs whereas build cost does not (handwave).

Re: Gitlab S-1

#143

Post by ncphil »

riffic wrote: post #47
HideousKojima wrote: post #34

Earlier quoted context omitted.

Docker is the main one I can think of that has flopped financially despite being widely use.

Docker has never gone public. https://www.crunchbase.com/organization/docker

... and it hasn't actually flopped. It just reached its level of... usefulness. As others commented a few weeks ago in a different conversation, Swarm had/has significant utility for smaller deployments, but K8S has sucked the air out of the (marketing) room. So life goes on, as does docker and Docker Hub. Many of us small potatoes users will continue to use docker until we can't, and then probably wind up on podman, or lxd. That will be OK too: as long as the work gets done. We survived the demise of Solaris Freeware, we'll survive this too.

Re: Gitlab S-1

#144

Post by jorams »

toastal wrote: post #90
whateveracct wrote: post #35

Earlier quoted context omitted.

It's only a matter of time before I move to sourcehut I think.

I paid for it recently. So far it's been a mixed bag for me. The core works as intended, but little annoyances can add up. I love that the design is small and light, but almost none of the languages is use are supported by Pygments for highlighting so someone browsing the code may find it off putting (GitLab I can use gitattributes to select a different but compatible Rouge highlighter). I like that NixOS is a first-…

> almost none of the languages is use are supported by Pygments for highlighting

What languages are those? Pygments supports a lot of languages[1].

[1]: https://pygments.org/languages/

Re: Gitlab S-1

#145

Post by marc__1 »

brianwawok wrote: post #127
marc__1 wrote: post #120

Earlier quoted context omitted.

> is anyone actually doing that at scale? per the prospectus on page 16 the answer is definitely yes: Net Dollar Retention Rate for customers who paid more than $100,000 in ARR is 283% as of 12 months ended January 2021 and 383% for YTD 2021, meaning this customer cohort increases on average the spent by 2.8x. The highest net-dollar retention rate among all SaaS publicly-traded companies, whose average is around 120%…

That average is across all price points though right, not 100k+ customers? That seems a very apples to oranges comparison.

Fair enough: the average dollar retention rate among all gitlab's customer is 152%, behind only Snowflake, Blend Labs, nCino and UIPath afaik.

I was just trying to emphasize that for the highest paying cohort, retention is best class.

Re: Gitlab S-1

#146

Post by nawgz »

shortstuffsushi wrote: post #92
nawgz wrote: post #77

Earlier quoted context omitted.

I am not a big shop - I work on a team on the order of 10 We use GitLab as our "one place to do the entire software development lifecycle". It's a really good CI/CD runner in my opinion, the .gitlab-ci.yml files are expressive and enable reuse thru a pretty nice inheritance model, and integrating new service (container) builds is literally 4 lines of code to have every push build a new container and put it in GitLab…

> we can drop 4 lines into an JS/TS repo and have it publish Could you talk a bit about this, or link out to any docs they've got for this? I'm curious about setting that up

I will give a high-level overview. Essentially, it is a workflow runner. You can set up "jobs" in a "pipeline" (dependency graph of jobs), and each job is just a bit of yaml. This yaml has individual keys controlling things like running a script, configuring the environment, controlling the docker image executing the job, etc..

These jobs / yaml blobs can be included into other files / projects using another one of these keys, "including" another job/pipeline via configuring the path to the repo & path to the file you want to import. You can override any properties really easily on these includes as well. Anyways, my .gitlab-ci.yml for building a container (any repo containing a top-level Dockerfile works zero-config, non-top-level can be configured) looks like this

    include:
      - project: 'public-tools/gitlab-extensions'
        ref: master
        file: '/.gitlab/ci/Docker-build.gitlab-ci.yml'
Then of course that file does the things to run a `docker build` script with secrets passed as build args etc

Re: Gitlab S-1

#147

Post by tyingq »

chx wrote: post #96
benatkin wrote: post #71

I'm grateful to GitLab for providing an alternative to GitHub, and an open source one. It's an open core product with the community edition providing a lot of value. Here are some community hosted instances: https://wiki.p2pfoundation.net/List_of_Community-Hosted_GitL... The CI system is quite powerful, and Travis CI's struggles before and after acquisition has shown that it's hard to host a major CI platform. I hope…

Who can edit that page? https://git.drupalcode.org/

The owners/maintainers listed here probably:

https://git.drupalcode.org/project/drupal/-/project_members

Re: Gitlab S-1

#148

Post by INTPenis »

ignoramous wrote: post #112

Gitlab is one of the pioneers of "remote-first" [0] and "building in public" [1], to the extent of sometimes even live-streaming CEO meetings [2] and sales pitches [3] Gitlab, I believe, informs the common strategy behind most other source-available ycombinator enterprise startups: the buyer-based open-core model [4] Congratulations Gitlab. You're far from a copycat and deserve all the success for relentless executio…

Yeah I absolutely support Gitlab and love seeing new projects use Gitlab over Github.

But to be fair, they have a massive backlog of issues to fix. Basic issues too, like variables not expanding correctly in CI jobs, or Google not being able to index projects on gitlab.com unless there's another page already linking to it.

I've been using Gitlab.com and Gitlab on-prem since 2013 and over the years I've found many of these bugs that I feel should be top priority instead of new features.

Re: Gitlab S-1

#149

Post by danielmarkbruce »

alberth wrote: post #36

I realize plenty of tech companies IPO and aren’t profitable. But it seems scary to be losing more money than what you generated in total revenues. REVENUE: 2021: $152m (loss of $192m) 2020: $81m (loss of $130m) EDIT: reworded for clarity.

The majority of their costs are sales, and R&D. Those will almost certainly start to grow much slower than sales, and then they'll be fine.

They have to take customers while they can.

Re: Gitlab S-1

#150

Post by nawgz »

wdb wrote: post #102
nawgz wrote: post #77

Earlier quoted context omitted.

I am not a big shop - I work on a team on the order of 10 We use GitLab as our "one place to do the entire software development lifecycle". It's a really good CI/CD runner in my opinion, the .gitlab-ci.yml files are expressive and enable reuse thru a pretty nice inheritance model, and integrating new service (container) builds is literally 4 lines of code to have every push build a new container and put it in GitLab…

NPM Private registry doesn't really work for me with Yarn and NPM v7 when trying to run binaries. This is a major blocker for a lot of things. Also the `npm install` is really flaky multiple times a day I get 404s for packages in the private registry. You need to keep retrying jobs that use that command until succeeds.

I experienced some initial configuration pain with their Package Registry, but after generating PATs for local use and passing secrets thru the CICD build runner nicely - and using yarn - I have had no issues publishing nor installing my own private modules.

Here are the commands I suggest you run to authenticate your local machine to GitLab:

    yarn config set "@example:registry" "https://gitlab.example.com/api/v4/packages/npm/"
    yarn config set //gitlab.example.com/api/v4/packages/npm/:_authToken ""
    yarn config set //gitlab.example.com/api/v4/projects/:_authToken ""
When you need to debug, the output of

    yarn config list
is pretty concise and helpful. Be aware there can be local per-config folder so if you have trouble in a specific project you should issue that command there and check for incorrect registry settings etc. I also suggest you fully commit to yarn or npm, they are definitely different enough to be awkward to combine.
Post reply on HN