GitLab 8.10 Released with Wildcard Branch Protection and Manual Actions for CI
about.gitlab.com
about.gitlab.com
Thanks for naming an example of a view we can improve, I've screenshotted the issue view in http://imgur.com/a/0FREI Suggestions are very welcome.
Glad to hear CI is working out for you. It was great seeing CaptainTrain write about it yesterday https://blog.captaintrain.com/12703-building-on-gitlab-ci
I see some issues discussions, workarounds and seems like it does allow -cache directories but it is unclear how it all works.
for us( unfortunately) its 40 min vs 5 min build times, with/without caches.
1. Build artifacts (recommended) http://docs.gitlab.com/ce/ci/build_artifacts/README.html
2. Cross Runner Caching (not implemented yet) https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/...
3. Single Runner Caching https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma... Edit: a better explanation is in http://docs.gitlab.com/ce/ci/yaml/README.html#cache
4. Container registry (not possible for Maven, etc.) https://about.gitlab.com/2016/05/23/gitlab-container-registr...
I agree it is confusing and my knowledge might not be accurate. I've asked CI experts to improve the documentation in https://gitlab.com/gitlab-org/gitlab-ce/issues/20155
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).
- hide "Open", "Closed", "All" in a status dropdown
- Move the RSS icon somewhere to a dropdown + use a meta tag, people who use it will figure it out
- Move "Filter by name" to the filter menu or even better: switch the top search to "Search issues" with a dropdown to change it again
- Move "Issues, Labels, Milestones" where "Open, Closed, All" was before. Boom, one less horizontal navigation.
- Remove the TODO icon at the top right
- Remove one or two items of the project navigation
- Combine some of the project settings items, especially the lesser used
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.
I've added your last suggestion to https://gitlab.com/gitlab-org/gitlab-ce/issues/20154
I've been annoyed these last few releases by high memory usage. Every day, my backups fail due to ENOMEM.
I have adjusted unicorn-worker-killer to undo the increased memory usage you did a few releases ago:
unicorn['worker_memory_limit_min'] = "300*(1024**2)"
unicorn['worker_memory_limit_max'] = "330*(1024**2)"
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`.
http://weblinksdca.s3.amazonaws.com/Screen%20Shot%202016-07-...
How many unicorn workers are you using? For 2GB systems, I'd recommend at most 2 rather than the default 3. Some discussion about this is here: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/1279
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.
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.
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.
Wow, that is awesome to hear! The issue board is landing in 8.11 https://gitlab.com/gitlab-org/gitlab-ce/issues/17907 and the latest mockup looks pretty sweet https://gitlab.com/gitlab-org/gitlab-ce/issues/17907#note_13...
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?
Great idea and a wish of me for years, I've made an issue https://gitlab.com/gitlab-org/gitlab-ce/issues/20182
> 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.
I do wish cross-repo pull requests could be imported. (http://docs.gitlab.com/ce/workflow/importing/import_projects...). Right now we have to hang on to a small number of GH accounts just to keep several years of that valuable history.
Good point about importing cross repository pull requests correctly, I've made a feature request for it in https://gitlab.com/gitlab-org/gitlab-ce/issues/20153
Keep up the good work!
This is due to us only using a single NFS server. With the release of 'Multiple Repository Mount Points' today we can start adding more servers.
Long term we want to move to distributed storage with Ceph and we hired a consultant to help us with this that started last Monday. Also see https://gitlab.com/gitlab-com/operations/issues/1
For more general GitLab.com questions the options are listed on https://about.gitlab.com/gitlab-com/
Free subscribers can use the GitLab.com Support Tracker https://gitlab.com/gitlab-com/support-forum/issues if they have questions.
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.
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.
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.
Thankyou!
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.
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!
http://docs.gitlab.com/ce/markdown/markdown.html#multiline-b...
I've created a Merge Request to add a note to the top of the document encouraging people to view it within GitLab: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5440
You can check out the Multiline Blockquote example in all its glory here: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/mark...
That page renders correctly if viewed through the repository browser (which apparently always renders Markdown as GFM): https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc//mar...
Is the Kerberos Ticket based git pull Enterprise only?
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 :)
The Kerberos functionality was contributed by CERN to Enterprise Edition https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6 and CERN left this comment https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/685#n... on the Kerberos CE contribution.
I think Kerberos Ticket based git pull is Enterprise only.
I've been wanting this on GitHub for so long. The example in the docs seems broken to me though - http://docs.gitlab.com/ce/markdown/markdown.html#videos
I've added a note to the top of the document encouraging people to view it within GitLab: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5440
You can check out the Videos example in all its glory here: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/mark...
It appears however that it doesn't currently work correctly with files in the same repo, just with absolute links. I've created an issue for that here: https://gitlab.com/gitlab-org/gitlab-ce/issues/20189
- 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)
I picked `>>>` because it mirrored the triple-backtick syntax for fenced code blocks, and `>` was already used for single-line blockquotes.
You can see the feature proposal I filed at https://gitlab.com/gitlab-org/gitlab-ce/issues/16564, and the merge request I submitted to implement the feature at https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3954, for some more insight into how this came to be.
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.
For the record, it's pretty easy to change your notification settings.
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.
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