GitLab 11.7 Shipped with Releases, Multi-Level Child Epics, and NPM Registry
about.gitlab.com
about.gitlab.com
[0] https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1...
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 boleary [at] gitlab.
@boleary-gl have you all considered having someone dedicate time each day / week to prioritizing community issues?
Oh jolly good! This exact feature was something I've thought about as useful for microservice stacks where you need interconnected background services for integration testing. Very nice of you to contribute this feature, thanks! Hopefully this will be merged at some point.
At work we are using Atlassian products, they would be so efficiently replaced by just Gitlab
Maybe it was a regression in an old version?
I've found this invaluable for working solo or in group projects.
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.
Looking through (browsing repositories) there is almost NO adoption to gitlab.
I don't know the figures, but the teams I encounter using Gitlab are self-hosting, you aren't going to be able to browse their (private) repos.
We used to have a Explore link on our homepage to https://gitlab.com/explore because HN asked for it but it got dropped.
I've asked to reinstate it in https://gitlab.com/gitlab-com/www-gitlab-com/issues/3713
Gitlab Cloud v Github Cloud. Github cloud is easier to grok, and get started versus gitlab, adoption on github is very visible, and immediate from first landing.
Gitlab On Premise v Github Enterprise. Gitlab wins in offering (open source, and complete ci/cd). However, I would argue that the marketing is much stronger with Github. Github has a streamlined message which you can consume easily and then once you're in you get deeper into the meaning of.
This is what I am referring to. Model or not, it's something that is a barrier to entry.
Github:
1. Straight to the point. For developers. Host code, work alongside millions of developers or your team. 2. Registration form right next to message. Immediate start. No need to think about much else. Let's get started. 3. Let me check their features (just in case) keep scrolling 4. Oh wow okay, woah another register form right here easy.
Gitlab:
1. Message makes me think. "A full DevOps tool~chain~.*" Why the asterisk? I'm already distracted. 2. Okay, I can manage projects, sourcecode management, CI/CD, great. 3. Get started for free... 4. Immediately see "try x for y days"... thinking "so is this paid?" 5. Look down and see I don't need to do that.
I have to do more thought now, why not just let me register from the homepage and auto-subscribe me to the gold plan and let me know that, you don't require a credit card either way.
---
This is purely from the Cloud perspective, but there is much more thinking required for Gitlab than Github.
---
Mind dump of subjectivity:
For hosted / feature-set, the way github illustrates their feature offering is much better than the table on the gitlab homepage as well. It's more about how much time do I have to vet a product. For someone who is purchasing enterprise they are more likely to invest more time, but overhead or information overload or time to trial is a real thing and can be quantified.
---
As a note, I like gitlab, the product is great, the marketing could use some work is all. Everyone there does a great job.
I'm not sure what it's doing, but at least it's an easy fix.
I found the operation of on-prem GitLab to be a bit of a PITA back then, has that changed? There was a whole bunch of rake tasks and junk you needed to run to upgrade and it required a shutdown of the system.
(Source: work at GitLab, and I wouldn't If we had to manage the infra by hand vs. omnibus/k8s)
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.
I more recently used Gitlab on Ubuntu using their omnibus package for Ubuntu and the upgraded over multiple versions to get onto a later version of Gitlab. The upgrade process was a lot smoother (no fighting to build gems on SmartOS and patching all over the show to get gems and other dependencies to compile).
I also did a MySQL to Postgresql migration. You have a bit of downtime with the process which chef sorts things out post upgrade of the omnibus package. I did turn the unicorns and disabled ssh logins while I was upgrading the omnibus package just incase something went wrong during the upgrade.
We're upgrading two or three times a month, and I don't remember having had any issue just letting it update itself for at least a year.
Gitlab's downtime when upgrading the docker image is about 1 - 3 minutes every time, which hasn't been an issue for us (and otherwise I'd just schedule it for midnight)
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.
My team of devs doesn't have a dedicated sysadmin.
To troubleshoot your problem smoothly, I'd advise not to modify your GitLab instance intentionally, for instance, applying own custom patch, changing database schema, etc.
I previously managed Atlassian instances and I dreaded ever touching the servers.
GitLab def has there shit together in this regard.
edit: I forgot, when issue, their docker container uses tmp memory that never seems to free itself. I occasionally (once a year) have to rm and recreate the container, which isn't a huge deal for me.