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

GitLab 11.7 Shipped with Releases, Multi-Level Child Epics, and NPM Registry

about.gitlab.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: GitLab 11.7 Shipped with Releases, Multi-Level Child Epics, and NPM Registry

#51

Post by nextos »

merlincorey wrote: post #23
nextos wrote: post #5

Tangentially related, but GitLab has developed surprisingly good (albeit still incomplete) support for org-mode and many other markup languages. So it's extremely easy to publish say a wiki built with org and they render it beautifully. I've found this invaluable for working solo or in group projects.

I definitely agree, because I use org-mode and gitlab, personally. However, they are just using the same ruby package that Github uses to render the org-mode to HTML... unfortunately it is far from perfect. Still, it's MUCH better than the go version in Gogs, so there's that.

I know, but on Gitlab you can additionally run an Emacs container to use org to export to HTML.

Re: GitLab 11.7 Shipped with Releases, Multi-Level Child Epics, and NPM Registry

#53

Post by olingern »

boleary-gl wrote: post #33
baaym wrote: post #13

I've been enjoying GitLab at my last three employers now, with the CI integration being the most liberating feature compared to the traditional CI providers. Especially the Docker CI runner gives you a great integration test environment, and I'm impatiently waiting for this MR [0] that will allow dependant containers to also talk to each other. It's the last missing piece for my ideal CI setup. [0] https://gitlab.com…

GitLab product manager for Verify (CI) here. Thanks for bringing this up I hadn't seen your contribution! I think this is a great idea. I know the technical team has been overwhelmed with community contributions as of late - which is a good problem to have but one that we're still solving. I'm going to try and shepherd this one along myself. If you want you can reach out to me on Twitter @olearycrew or my email is bo…

That thread looks rough. Kudos to the MR author for sticking it out.

@boleary-gl have you all considered having someone dedicate time each day / week to prioritizing community issues?

Re: GitLab 11.7 Shipped with Releases, Multi-Level Child Epics, and NPM Registry

#54

Post by snorremd »

If GitLab can pull off the npm registry well this might be the beginning of a universal package management server built into Gitlab. A bit like the self hosted Nexus registry or Artifactory.

Not sure if it wouldn't be just as well to run Nexus OSS instead though? https://www.sonatype.com/nexus-repository-oss

You might not get as tight of integration as Gitlab will provide, but the Nexus OSS repository provides some nice features in terms of cleaning up old artifacts, some disk usage policies, etc.

Re: GitLab 11.7 Shipped with Releases, Multi-Level Child Epics, and NPM Registry

#55

Post by lbotos »

meddlepal wrote: post #48
lbotos wrote: post #16

Earlier quoted context omitted.

It's a lot easier, and dead simple to run a small single server install. When you start scaling, it gets a little harder, but our vision it to leverage K8s for that type of deployment. (Source: work at GitLab, and I wouldn't If we had to manage the infra by hand vs. omnibus/k8s)

Any comment on how well the single server install scales before needing to invest in the more complex HA solution?

Sure! This depends on your orgs "capacity for risk." We don't recommend more than ~300 on a single node just for the developer area. If you have 300 people relying on a literal SPOF (especially a dev shop) that's gonna hurt if there are any problems. That said, I'm aware of customers running a single 132GB node that serves somewhere between 3000-5000 devs. (Please do not go this far)

I'd say at the 150 or so developer mark, we should start talking about scaling (adding a second Geo node for failover at a minimum) or if you need more robust uptime requirements, going towards a more active-active distributed cluster. I use the word "distributed" and not "highly available" as we like to find the right fit for each org. Some orgs need true HA, and it takes something close to ~30 servers to do it. Others, just can benefit from some web frontends, and separating out the DB layer, and potentially traffic shaping to separate CI load / User load.

Re: GitLab 11.7 Shipped with Releases, Multi-Level Child Epics, and NPM Registry

#56

Post by brodock »

IloveHN84 wrote: post #52

Why only love for npm/JavaScript world? I still prefer having a separate registry for packages (e.g. SonaType Nexus) and let GitLab host code + CI

There are more planned. You can read it here: https://about.gitlab.com/direction/package/

Re: GitLab 11.7 Shipped with Releases, Multi-Level Child Epics, and NPM Registry

#57

Post by krotscheck »

olingern wrote: post #53
boleary-gl wrote: post #33

Earlier quoted context omitted.

GitLab product manager for Verify (CI) here. Thanks for bringing this up I hadn't seen your contribution! I think this is a great idea. I know the technical team has been overwhelmed with community contributions as of late - which is a good problem to have but one that we're still solving. I'm going to try and shepherd this one along myself. If you want you can reach out to me on Twitter @olearycrew or my email is bo…

That thread looks rough. Kudos to the MR author for sticking it out. @boleary-gl have you all considered having someone dedicate time each day / week to prioritizing community issues?

Ehn, it's no biggie. Tagir did most of the code (and owns the commits), I'm just a hominid rebase bot.

Re: GitLab 11.7 Shipped with Releases, Multi-Level Child Epics, and NPM Registry

#58

Post by marmaduke »

stanhu wrote: post #35
marmaduke wrote: post #6

I like GitLab but noticed my Docker container running it is steadily requiring more memory to run smoothly. It’s sitting at 12GB right now, which is a little too high for my taste. I wish there were ways to reduce this.

Could you show the output of `ps aux` inside the container? Also note that GitLab Omnibus will add more Unicorn processes the more available RAM it has in the system. You can turn off that automatic scaling by lowering the number of processes via https://docs.gitlab.com/omnibus/settings/unicorn.html .

Thanks for the reply, here's my late response. I've pasted the output of ps aux here https://gist.github.com/maedoc/1f6e568d44541d7734204d294c98a..., though now it seems to have dropped significantly. The only change I seemed to have made that could account for that is moving from a local disk storage to NFS storage, maybe there's some caching accounting effect..
Post reply on HN