Nice. It keeps getting better with each release. Speed seems to have improved. The only place where github is better is in the UX. Gitlab is ugly on a small laptop screen, in issues view it has three top bars that becomes really annoying. It reminds me old IE days when you had a lot of bars.
Apart from that, everything is amazing, I use it daily, specially Gitlab CI, which is one of the best CI ever.
Wow, thanks Allen for the clear suggestions. My initial thought is that we can do some of these. It would be awesome if we can have one less layer of horizontal navigation. I've created https://gitlab.com/gitlab-org/gitlab-ce/issues/20154 to follow up on this. If you or others have any more suggestions feel free to add them there as a comment.
Sure, thanks. I was trying to only change the issues page and stay within your overall layout.
Additionally I would probably move the user icon from the top right to the left and replace the hamburger, since the navigation below is really the user menu.
Hey sytse, always glad to see you being so involved around here :-D. Here's some random feedback (not sure this warrants creating some issues, just food-for-thought).
Constant stream of increasingly polished UI updates has been a huge driver for adoption internally.
GitLab is being increasingly used not just for code but also for project management, collaboration and possibly even tier-1 support tasks, and emphasis on features such as email sinks, deadlines and (hopefully soon) label-backed boards is just fantastic. As soon as boards merge we might very well be dropping Trello.
Since it's being increasingly used by non-tech folks, the second bigger barrier to adoption UX-wise over here is localization. Months (years already? time flies!) ago the rationale was that tech teams know english so GitLab was fine with no localization, but things seem to come to a change.
"Codeless" projects is definitely something of interest for non-tech folks too (i.e no git repo/MR/CI but issues and wiki), is that out of scope for GitLab?
Any plans for non-linux (specifically Mac OS X) shared runners on gitlab.com? This is definitively a factor in migrating some FOSS projects from GitHub+Travis to gitlab.com (shameless hint: https://github.com/arch-osx)
> Constant stream of increasingly polished UI updates has been a huge driver for adoption internally.
Yay, glad to hear that. We'll keep them coming, we're hiring UX designers and a UX lead at the moment.
> GitLab is being increasingly used not just for code but also for project management, collaboration and possibly even tier-1 support tasks, and emphasis on features such as email sinks, deadlines and (hopefully soon) label-backed boards is just fantastic. As soon as boards merge we might very well be dropping Trello.
To do support and email sink would be nice (in addition to reply-by-email that we currently already have). The issue for this is in https://gitlab.com/gitlab-org/gitlab-ee/issues/149 and if you like it I would appreciate a comment with your use case there.
> Since it's being increasingly used by non-tech folks, the second bigger barrier to adoption UX-wise over here is localization. Months (years already? time flies!) ago the rationale was that tech teams know english so GitLab was fine with no localization, but things seem to come to a change.
Translating GitLab is inevitable but we need a good trigger to start. Preferably a large organization that expresses this wish. The conversation is happening in https://gitlab.com/gitlab-org/gitlab-ce/issues/4012
> "Codeless" projects is definitely something of interest for non-tech folks too (i.e no git repo/MR/CI but issues and wiki), is that out of scope for GitLab?
> Any plans for non-linux (specifically Mac OS X) shared runners on gitlab.com? This is definitively a factor in migrating some FOSS projects from GitHub+Travis to gitlab.com (shameless hint: https://github.com/arch-osx)
If we do this we will likely charge for non-linux runners to make it sustainable. Of course you can already bring your own OSX runner by renting it somewhere and installing GitLab Runner on it.
and while that stops my server from falling over in the first 10 minutes, it does consistently fall over once a day.
Here is a screenshot of my htop, I'm not sure where to look next. 25% free sounds okay, but it's not enough to run a backup, or even run `gitlab-rake`.
We'll be doing more work in these coming months to profile and reduce the memory usage needed by GitLab so that all your tools can run comfortably in the 2GB range.
Hi. I have a 2gb synology nas I run Gitlab via docker...i may mod the nas to say 6gb or 8gb ... But trying to avoid that.
My Gitlab backup is ~5gb monolithic .tar.gz daily. Is there any reason the tar.gz is 1 huge file, would using Linux split stop these massive Worker threads and device utilization?
http://unix.stackexchange.com/a/61776/86052
An added benefit of splitting to a configurable max size is certain cloud vendors have a max filesize limit...like 5gb :/ when replicating the backup.
Strange, your screenshot shows 0.5GB free. I recommend configuring swap to prevent the system falling over. It shouldn't actively swap much with 2GB unless making a backup or something like that.
First off, I'll admit our documentation for caching needs improvement.
We do support caching of gem's and other file artifacts. There are tricks about file locations, but once you get the hang of it, it works well. See https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Ruby... for an example for Ruby. It's actually one of the sources for our new CI configuration templates!
But sometimes, you don't really want caching, you want artifacts. Caching is an optimization, but isn't guaranteed to always work, so you need to be prepared to regenerate any cached files in each job that needs them.
Artifacts, on the other hand, are guaranteed to be available. It's sometimes confusing because the name `artifact` sounds like something that is only useful outside of the build, like for downloading a final image. But artifacts are also available in between stages within a build. So if you "build" your application by downloading all the required modules, you might want to declare them as `artifacts` so that each subsequent stage can depend on them being there. There are some optimizations like declaring an expiry time so you don't keep artifacts around too long, and using `dependencies` to control exactly where artifacts are passed around. Again, complicated subject that is poorly documented. I'd be happy to help you figure it out for your use case (and then publish the learnings).
Have you looked at using a caching proxy or maven repo in front of GitLab? For our TeamCity builds we have ProGet sitting in front of the public NuGet and Maven repos, it caches the downloads so any machine on our local network can reuse them instead of downloading artifacts every time.
Nice! Good release !...
One thing that make the user experience way less friendly and make me worry about pushing as our main repo is the git push/pull speed....
Coming from GitHub or bitbucket it feels really slow. But I don't give up hope!
I can confirm this, self-hosted is incredibly fast - you'll wonder how you ever used gitlab.com or github.com for that matter. It's as fast as it is for me to push to a locally running git server to be honest.
As a side note: GitHub.com is hosted on Azure and that says a lot, at risk of sounding like a zealot - I have quite a bit experience with apps including office365 hosted on Azure and that platform has more than its share of problems internally, problem is that it's a bit black box that's run by one of the least transparent companies I've worked with, let's just say there are a lot of internal engineering problems especially around networking (DNS especially) and storage. While I'm sure gitlab could throw more resources at their instances they're probably limited by costs / going above what is offered for HN startups to try to lock them into the platform and that may not help given the aforementioned internal platform issues.
Rest assured, self hosting an instance for say 50-100 developers does not require much 'grunt' at all as long as your platform is stable and properly managed which I don't believe should be at all hard in 2016 assuming you have half decent systems engineers or use a decent hosted platform.
I'm sorry to hear you had issues with your new account. I assume it has to do with email confirmation. Please email support@ company domain to get help.
If you purchase GitLab.com Bronze Support you can email support directly for timely, personal and private answers. This costs $9.99 per user per year for next-business-day response time and is available in packs of 20 users.
Wow. Hard to believe the pace at which this progresses and the quality that they pull off while doing it. Great job!
The only big thing I miss (and I miss this with Github too) is a way to prioritise issues. Yes, I get it, you can label things 10 different ways and achieve most of what you get from a priority system. It doesn't replace the simple ability to get a list in order of the most important things outstanding in order. I want it to be easy to generate a list of 'urgent' and 'high priority' where the 'urgent' issues are listed ahead of the 'high priority' and not ordered randomly.
I use milestones, for that. I almost never set a "due date". I find the milestone feature useful for doing, well, lot of not milestone related things.
First, they have a three columns (unstarted / started / completed) which adds easily simple trello-like boards to your projects.
Then, issues in those columns are sortable, like you describe, to prioritize. Simple drag'n'drop, could not get easier.
And finally, I use their description as a "release note". When MRs mention tasks to run on deploy, I'll just add them in milestone description, and I'll have a central doc for release.
Btw @sytse, would be cool if we could assign issues to several milestones. That way, we could use milestones as "view" for a given set of issues, each being ordered differently. This would allow different teams to have different prioritization, with a central issue hub. All of that by "just" allowing an issue to be in several milestones.
If you want this behaviour I recommend using labels instead of milestones. Currently an issue can be assigned to only one milestone and this is the first time I hear this request.
Oh, no, actually, I love handling everything through milestones, as mentioned in previous comment :)
Was just mentioning the idea in case you found it interesting to upgrade milestones to a project management tool. You already took github, travis and docker hub, I'm sure you can take trello as well ;) Go champs!
Actually consider you maintain two versions:
8.10.x and 8.11.x now a bug happens in both version to which milestone do you add the issue
8.10.2
or
8.11.2
even if the bug happens in both? ;)
Good catch! Our Markdown documentation describes a lot of GitLab Flavored Markdown that will (currently) only work inside GitLab itself, not on the docs site which uses a completely different Markdown renderer.
Other GFM features are broken in the examples on that page, too. Looks like it was processed using a standard Markdown parser rather than a GFM-aware one.
The manual release feature is great! I was just pondering on how to do that. For anyone wondering where to start with Gitlab CI I wrote a short post about our very simple but still very useful CI setup: https://pilloxa.gitlab.io/posts/ci-with-gitlab-and-docker/
Glad to hear you like it. Thanks for your post. BTW now that we have the container registry you no longer need to create an account at Dockerhub I think.
We only release things as Enterprise Edition only if they are contributed to that repository. We never deprecate features from the Community Edition. See https://about.gitlab.com/about/#stewardship
In this case I think CERN contributed code for both SAML and Kerberos over time. The SAML code got merged into CE and we ended up spending a lot of time improving it, documenting it, and providing unpaid support. It turns out that SAML is more of a framework for creating standards than a standard :)
Yep, you're right, our Markdown documentation describes a lot of GitLab Flavored Markdown that will (currently) only work inside GitLab itself, not on the docs site which uses a completely different Markdown renderer.
I want to love gitlab but it's very slow on small machines (2gb). Worse is that they insist on this omnibus stuff which is all great if you have time on your hands. Any reason gitlab does not auto update?
This is lacking detail about the exact use case but either one of:
- use gitlab.com with private repos for free
- install from source to skip omnibus. I've been updating ours for a couple years now and it's always been simple. Bonus is that if you need a quick patch or even the occasional bespoke tweak you've got the git repo right there which has been invaluable.
- githost.io is a thing (contemplating migrating to it nonetheless because GitLab has really come so far that we don't need much patches anymore)
If you run it on a 2GB machine I recommend using the Omnibus package since it automatically kills and restarts processes that run out of memory (unicorn and sidekiq). You mention that Omnibus is great if you have time on your hands. I don't understand this remark, the of the Omnibus package is to allow you to install GitLab in 2 minutes. With the Omnibus packages you can use apt or yum to auto update.
I added the blockquote fence feature because I was getting tired of having to manually prefix every line with `>` when I was quoting a multiline message like an entire email.
I picked `>>>` because it mirrored the triple-backtick syntax for fenced code blocks, and `>` was already used for single-line blockquotes.
I'm sad to hear that this feels like reinventing the wheel to you. From my perspective, there existed an imperfect wheel that we "invented" a more powerful alternative to.
Now please tone down the incredible amount of unwanted mail you send to new signups, got my colleagues fairly puzzled after I insisted we use GitLab instead of GitHub. :(
A typical frequency would be 2-5 emails over the first 7 days after signup, then ~2/month afterward (unless you also sign up for security updates). I'd like to make a change so that it's 2-5 emails over the first 9 days after signup. About 80% of people only qualify for newsletters and one onboarding or confirmation email in the first week after signup, whereas people at companies we suspect more interested in EE and/or support will receive 1-3 extra from our business development reps. We try to limit our more "salesy" outreach with "lead scoring", an industry standard for IDing those most likely interested in those type of emails (see https://about.gitlab.com/handbook/marketing/demand-generatio... ).
The response to our emails is usually positive (sometimes even apologetic to the BDRs for slow response) as the BDR team can attest to, though we do get our fair share of unsubscribes (our reps include a one-click unsub link in their signature - highly unusual!) and the occasional two-word "f* you!" replies. Let me add that we don't ask for phone numbers from new signups and you will not be burdened with nonsense voicemails from us!
That being said, feedback like this is always a good catalyst to reevaluate and look for opportunities to adjust and improve. As stated in the first link I provided, "What [you] receive depends on how [you] came to find us and what we believe will be most helpful to [you]", so any specific feedback on how to be more helpful is greatly appreciated! -Hank Taylor
That's a rather rude, unconstructive way of asking for someone to do something for free for you. How about logging a bug, or if you have - linking to it here to get some additional traction?
Don't worry about the 'ce vs ee' thing, it makes no difference, it's all the same code and regardless, the company and the community care about the product and will respond.
