Almost Everything We Do Will Be Open

https://about.gitlab.com/2015/08/03/almost-everything-we-do-is-now-open

by jobvandervoort • 11 years ago

386 202 11 years ago

about.gitlab.com

As always, if anyone has any questions, we're here.

scrollaway7• 11 years ago

Well done guys. I've been thinking about completely open models for a while now; we have a similar model at work (on FOSS as well).

I'm a hardcore Github fan but I'm really impressed with what you've all been doing. The more I see your work, the more I want to switch.

jobvandervoort18• 11 years ago

That's great to hear.

You can give it a try / use it for free at GitLab.com (public and private).

We would love to hear what hardcore GitHub fans like you miss in GitLab. We want to be better.

AshFurrow• 11 years ago

It's so encouraging to see companies go open like this – thanks!

Fogest• 11 years ago

Are there any plans with the CI to allow me to download the artifacts from a finished CI task?

It would be nice at times to download old builds at certain commits that the CI server had built in the past.

lgp171188• 11 years ago

Would appreciate better support for the Integration-Manager workflow described in http://git-scm.com/book/be/v2/Distributed-Git-Distributed-Wo.... It is possible to use this workflow with Bitbucket and GitHub but not with GitLab (possibly due to the differences in roles and permissions). I had already raised a feature request for this some time back. Would appreciate your thoughts on this.

sytse33• 11 years ago

Can you maybe link to the feature request?

vezzy-fnord4• 11 years ago

Announcement itself is fine. The way you contrast "open" with "proprietary" is a bit jarring. It should be free versus proprietary, but if you find that undesirable, then just go with open/closed.

EDIT: Quite predictably, I got downvoted for asking people to use proper terminology and for promoting free software.

nanny3• 11 years ago

People just hate when you correct their semantics, don't take it personally. Many people also don't know the difference between free and open. Here's a popular article by RMS which explains the difference: http://www.gnu.org/philosophy/open-source-misses-the-point.e...

animefan• 11 years ago

That ship has sailed. Today, "open source" means "free" in Stallman's terminology. Asking people to use nonstandard terminology in order to promote a particular viewpoint is not reasonable.

athoik• 11 years ago

What about security issues?

Those will be in public too? Or you should contact by email when you have a security issue.

dewey• 11 years ago

"Sensitive issues, such as security issues with GitLab, will still be handled internally. We’ll create tracking issues for these on the public issue trackers that don’t contain exploitable information."

jobvandervoort18• 11 years ago

For sensitive issues you can email us at support at gitlab dot com.

_pmf_• 11 years ago

It's hard to compete against GitHub. I hope they will get some traction so we have an alternative to GitHub once it gets bought by MS (and becomes the next SourceForge).

nadams11• 11 years ago

Why would Microsoft buy github? They have their own.

RazzyP• 11 years ago

Can't beat em', eat em'.

kasbah• 11 years ago

Why did Google buy YouTube when they have Google Video?

achr2• 11 years ago

For the same reason they're using GitHub to host all of their new open source initiatives.

navait• 11 years ago

Is bitbucket considered not a competitor? I've found it quite suitable for anything github does, though I'm at max a 5 person team.

silverbax88• 11 years ago

BitBucket is far superior to GitHub. It's not even a question.

drinchev2• 11 years ago

Bitbucket is awesome. I'm using it for all non-essential repos that I have as a side/small clients projects. I'm paying for 5 private repos on GitHub and whenever I see that I don't use a repo that often I just move it to bitbucket ( I'm such a bastard customer - I know ).

Two examples, why I don't use BitBucket for big projects and essential clients :

1. Interface is not that good - e.g. makes it hard to manipulate issues. 2. Integrations with some CI is not as good as in GitHub.

aikah• 11 years ago

Github has a lot of social features, but as a git hosting service, Bitbucket is as good as Github. And Bitbucket has free private repos.

aardshark• 11 years ago

So if customers want to contribute to fixes for issues they raise, is there a an easy way for them to do that without revealing who they are?

jobvandervoort18• 11 years ago

Yes. All our customers have a direct line to our support. We ask them to raise issues there, not on the public issue tracker.

davexunit2• 11 years ago

This article uses a bit of openwashing to make "publicly viewable source code" seem "open". It's not. It's proprietary.

jobvandervoort18• 11 years ago

It is, we don't intent to be vague about this. I hadn't heard of the term openwashing, but I understand the criticism.

See also our license for our proprietary GitLab Enterprise Edition: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE

And the license for our open source GitLab Community Edition (MIT Expat): https://gitlab.com/gitlab-org/gitlab-ce/blob/master/LICENSE

TheLoneWolfling• 11 years ago

It is forbidden to copy, merge, publish, distribute, sublicense, and/or sell copies of the Software.

merb• 11 years ago

Isn't the copy a little bit vague? I mean if I want to help I need to copy it?

nightcracker2• 11 years ago

Well, you are. Let me read to you the definition of Open Source:

Open source software is software that can be freely used, changed, and shared (in modified or unmodified form) by anyone.

nadams11• 11 years ago

You are free to modify this Software and publish patches.
It is forbidden to copy, merge, publish, distribute, sublicense, and/or sell copies of the Software.

You might want to get a lawyer on the phone - because that seems contradicting to me. This is why you should stick with open source licenses that have been vetted by a team of lawyers already. You should check out the AGPL license.

sytse33• 11 years ago

The article is about the issues that will almost all be open. The complete quote you refer to is is "In fact, even our proprietary version of GitLab, GitLab Enterprise Edition, has a publicly viewable source code.". Can we be any more clear it is proprietary? We think it is notable that even the source code and issues of out proprietary edition are publicly viewable.

scrollaway7• 11 years ago

Your wording is fine. Parent is being far too cynical.

KingMob4• 11 years ago

Perhaps it's just me, but when they said the enterprise edition was "publicly viewable source code", I assumed they just meant it was "publicly viewable", with no further rights implied.

I don't think they're really openwashing here, and the article was pretty clear to me. Besides, the community edition and CI code are both true open source.

ZenoArrow3• 11 years ago

Isn't there a slight problem with having the EE code publicly viewable?

What I mean by this is, what's stopping someone from taking code from the EE, modifying it, and including it in the CE?

On the flip side, what if a feature released to CE is too similar to code in EE, even if the author of the patch never read the EE code for inspiration? Would GitLab be within their rights to stop it?

With these issues in mind, it makes more sense to me to have the EE code available by request only.

philtar2• 11 years ago

I apologize in advance for my short sighted question as I don't really know much about gitlab but my question is: does this mean anything for large file support in the community edition? I find it surprising there are no free solutions for large binary files other than perforce. Compared to most tools indie game devs use, perforce is a dinosaur.

Mathiasdm• 11 years ago

Mercurial has had support for large binary files using the 'largefiles' extension for several years now.

jobvandervoort18• 11 years ago

We will not bring Git Annex [0] to the community edition.

However, we do accept merge requests for Git LFS support [1]. This means that if this is contributed to GitLab, it will be available in the Community Edition.

[0] http://doc.gitlab.com/ee/workflow/git_annex.html

[1] http://feedback.gitlab.com/forums/176466-general/suggestions...

jordigh• 11 years ago

    I find it surprising there are no free solutions for large binary
    files other than perforce.

There's in fact lots of tooling in Mercurial to handle this precise problem, as well as gigantic repos. Mercurial's extensibility with these scaling problems, in fact, is why Facebook has chosen it. If you're not married to git, try checking out Facebook's Mercurial extensions.

philtar2• 11 years ago

What web interface supports LargeFiles?

zxcvcxz• 11 years ago

Decided to switch to gitlab when I realized github refused to release their tools on Linux even though according to stackoverflow statistics Linux users make up over 20% of programmers, matching the number of OS X programmers.

It's unfortunate that they make a living off open source software created by a lead Linux developer but they act like Linux doesn't even exist.

Not a big deal though, the userbase on github is worse than facebook or 9gag.

Gitlab isn't much better than github when it comes to openess, but it seems to be the best alternative so far.

yjgyhj• 11 years ago

Not a big deal though, the userbase on github is worse than facebook or 9gag.

Found the grumpy linux user ;)

klapinat0r3• 11 years ago

Which tools are you talking about?

marcosdumay• 11 years ago

Git.

aidenn0• 11 years ago

I assume they're talking about https://mac.github.com/

hk__24• 11 years ago

It's unfortunate that they make a living off open source software created by a lead Linux developer but they act like Linux doesn't even exist.

They do contribute back; they’ve done plenty of contributions to Git. Also, GitHub tools are really useless when you’re used to vanilla git.

nhumrich• 11 years ago

Just saw that gitlab now offers free hosting, you only pay for support (only if you want it). Do enough people really pay for support in order to keep gitlab from going under? Free software is one thing, but free hosting? It just blows my mind how they can offer such a thing.

nightcracker2• 11 years ago

Github does exactly the same with Github Pages.

KingMob4• 11 years ago

Lots of places do it. Disk space relative to code size is extraordinarily cheap. Just look at the granddaddy, GMail. Google gave away 1 GB per user back in 2004 because they figured the ads would support it.

nadams11• 11 years ago

Free software is one thing, but free hosting?

Hosting basically boils down to the fact that ~98% of your users will use a small portion of your resources. This is why hundreds - even thousands - of users are shoved onto a single shared server (all without ever having a problem). Considering disk and bandwidth is cheap - it's really inexpensive to host users. 2% of your users will attempt to use 50% or more of your resources - and those are the ones that you kick to the curb or arrange some sort of payment.

I used to do free web hosting and now have switch to just free source code hosting.

A perfect example of this is this story [1]. I'm sure a good 90% of people who sign up for the free slack service only use a small blip of usage.

[1] http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-...

jobvandervoort18• 11 years ago

We do not make substantial money with GitLab.com.

It gives us the possibility to run GitLab on a very large scale. This helps us finding performance and scaling issues that otherwise would go unseen. In short, it allows us to make GitLab even better.

drinchev2• 11 years ago

If this is really the case and your business model is aligned with this, there's nothing else to say, except "Congratulations!".

I didn't know that this can go so well for end-users in such a competitive environment. I hope I hear more arguments like these from other tech companies.

How do you call this model? I guess freemium doesn't match with how you make the benefit out of the website.

odonnellryan3• 11 years ago

Diskspace and bandwidth are relatively cheap!

brainsiq• 11 years ago

You might wanna check out the twitter feed before jumping into their free hosting. Looks like they have had a lot of issues with connectivity/stability over the last few weeks at least.

https://twitter.com/gitlabstatus

jobvandervoort18• 11 years ago

We're seeing a lot of growth on GitLab.com. We just quadrupled the amount of instances running GitLab.com and are working hard on improving stability.

mrmondo3• 11 years ago

We've been enjoying GitLab for quite some time now, but I have to say with every new release they always seem to break something critical for us, there seems to be far too many regressions and many of them are not communicated evening with their paying customers - for example the latest one that's been causing us grief: https://gitlab.com/gitlab-org/gitlab-ce/issues/1974

jobvandervoort18• 11 years ago

We're actively working on finding a solution for this. We understand this is not a nice development for many of our users.

We do not want to inadvertently break the workflow / remove essential features without informing our customers in advance. And we will always work hard to ensure that if that does happen, we find a good solution for all parties.

If you do find that this is the case for you, as a customer of GitLab, please never hesitate to contact us through our support channels.

odonnellryan3• 11 years ago

Not to be rude, but isn't their software open source? Can't you try and patch it yourself?

oblio2• 11 years ago

If I've read his post correctly he's a paying customer. Surely that has to count for something :)

dudul2• 11 years ago

Nice. I really like GitLab. Made the move after GitHub started focusing on social justice instead of technology (plus I was tired of the hypocrisy of them making money from OS while keeping all their sources close), and I don't regret it.

jobvandervoort18• 11 years ago

Great! Anything you miss, coming from GitHub?

dudul2• 11 years ago

Not really for now.

The only thing, which doesn't really depend on you I assume :), is I wish GitLab was used more often as an authentication mechanism by other services. I don't know if GitLab is actually an OpenID provider or if it's just because it's not popular enough yet.

ojanik• 11 years ago

Coincidentally, I just installed GitLab to try it out for our small team to replace BitBucket + Jira. And while its more than capable filling Bitbucket shoes the issues subsystem is probably worse than github's and nowhere near flexible as jira.

Most notably: Missing more sophisticated workflows. Search for issues using multiple labels. Search for issues across multiple projects.

We would also love to be able to do simple time tracking against issues.

Is there no reasonably priced product out there that would fit our (rather simple) needs?

audessuscest• 11 years ago

I agree, we're using gitlab too and the only problem is the lack of ticket system feature (due date/alert reminder, multiple people assignment, advanced filters, simple markdown text editor for client, time tracking, edit default label for all project,...) otherwise we hightly recommend it.

sytse33• 11 years ago

Thanks, we're looking some of these but we want to keep it light and easy to use at the same time. Please be aware that some scrum tools also integrate with GitLab https://about.gitlab.com/applications/#scrum-boards

technomancy2• 11 years ago

After my experiences with Jira, "nowhere near as flexible as Jira" sounds like high praise.

codegeek2• 11 years ago

Good timing. Recently installed Gitlab Community edition on DigitalOcean (one click install) and so far loving it.

Some issues:

- Does it have a default task management tool or we need to integrate a 3rd party ? Couldn't find it in the forums yet

- The UI is a bit clunky in terms of navigation. For example, being able to move from the homepage level to specific project back and forth is a bit confusing. Would love a re-design of UI.

EDIT:

Lot of feedback that I can give. So far:

- Make it easy to navigate between index page and specific groups/projects. May be on login to index, just show a dashboard with all groups/projects that I am part of. If Admin, then show me additional options like what you have in "Admin Area" menu. Here is one idea. Just show all menu options in the left sidebar and split it like:

    - Home

    - Groups

        - Projects

          - Project 1

            - all menus that shows up for projects

    - Admin Area

      - Profile Settings

      - Users

      - Mail Settings

- User profile management is not that good for admins. For example, just yesterday one of my developers got locked out and I could not reset his access via the UI. I had to go in the config files to update the lockout timestamp.

- Also for new users, as admin I want the control to add them as verified user already. Currently I don't think that options is there in UI unless we fiddle with the code.

- For email driver, a simple form in UI will be nice to have. For example, if I want to use Mandrill, give me that option in the UI.

Bottomline is that even though we are developers, we don't want to change the .rb files for Gitlab and instead focus on an easy UI.

jobvandervoort18• 11 years ago

Happy to hear!

Does it have a default task management tool or we need to integrate a 3rd party ? Couldn't find it in the forums yet

You can use Issues, which comes in every project and can be linked all throughout your GitLab instance. They also integrate with merge requests and can be used 'Kanban' style by using milestones. See our own for GitLab's issues: https://gitlab.com/gitlab-org/gitlab-ce/issues

You can also integrate many of the popular systems, such as JIRA, Asana, Trello.

The UI is a bit clunky in terms of navigation. For example, being able to move from the homepage level to specific project back and forth is a bit confusing. Would love a re-design of UI.

We're working very hard on this. The coming release will add more context to the menu and we're looking to improve it further both in terms of design, as well as UX.

It'd be great if you could share us your thoughts on how we can improve this.

codegeek2• 11 years ago

see my edited response.

oblio2• 11 years ago

Some proofreading issues related to the CI webpage (https://about.gitlab.com/gitlab-ci/). ). They're minor and easy to fix but I think they would help regarding sales:

-> Multi-platform since you can executes builds on Unix, Windows and OSX.

-> Stable because the GitLab CI is on a different machine that(n) the ones that perform builds.

Also the whole phrasing is a bit weird, I'd change it to:

Key feature: description.

The way it is now those phrases seem a little clunky and unnatural.

A totally separate issue, what are the limitations for the CI stuff? Build per day/per OS/whatever?

sytse33• 11 years ago

For task management you can use the build in issues and tools that integrate with that https://about.gitlab.com/applications/#scrum-boards

Your navigation remarks are spot on and inspired me to make this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/2225

Doesn't the lockout expire at some point? I agree it would be nice to reset from the UI.

Mmm, I thought that if an admin added a user they didn't have to verify their email.

Do you mean something like project services? http://doc.gitlab.com/ce/integration/README.html

I agree that your shouldn't change .rb files. Please contribute any improvements you make so we can include them.

ausjke3• 11 years ago

Still using Redmine for self-hosting here, Gitlab is too heavy for small teams. Thought about trying Phabricator but then its various components with strange names stopped me from trying, plus it seems clunky for small team too.

jobvandervoort18• 11 years ago

What makes you feel GitLab is too heavy for small teams?

In terms of load, it can run on a Raspberry Pi.

ausjke3• 11 years ago

CPU

    1 core works for under 100 users but the responsiveness might suffer
    2 cores is the recommended number of cores and supports up to 100 users
    4 cores supports about 1,000 users
    8 cores supports up to 10,000 users

Memory

    512MB is too little memory, GitLab will be very slow and you will need 250MB of swap
    768MB is the minimal memory size but we advise against this
    1GB supports up to 100 users (with individual repositories under 250MB, otherwise git memory usage necessitates using swap space)
    2GB is the recommended memory size and supports up to 1,000 users
    4GB supports up to 10,000 users

mrmondo3• 11 years ago

We use Redmine for ticket / issue / task tracking as well as rough timesheeting, and we use gitlab and gitlab CI along side it. I quite like how quick Redmine is and how it just gets out of your way. We find gitlab to be pretty quick however upgrades are painful due to regular bugs / regressions.

Ideally I'd like to see something like Taiga and Gogs together which I think would absolutely fly.

ausjke3• 11 years ago

Redmine works well with git too, the only thing missing for me is a nice code-review plugin.

neandrake• 11 years ago

I recommend giving Phabricator a try. After evaluating several different tools we ultimately went for Phabricator. When I initially looked at it in ~2012 I was put off for similar reasons:

1. References to pokemon on main pages 2. Confusing names for features 3. Written in PHP (this was an initial bias from my prior experience with the language and belief that such a language wouldn't be used to maintain a large-scale application).

These three points led me to believe that Phabricator was not a first-party application but just PHP glue tying together other open source applications. With this in mind, along with the pokemon, I wrote it off as some highschool/college project and turned my attention elsewhere.

I took a fresh look at it in 2014 and realized several of these misconceptions. The developers of Phab tend to be light-hearted and embrace some humor in development. This has proven to be valuable in sustaining good-natured development teams and keeping code-criticisms well-intentioned. They also have a "serious" setting which tones down some of the language in the application itself.

The feature names can be confusing, which is a valid criticism though after a week or so it doesn't tend to interfere with work. The most difficulty in adopting Phabricator has been getting developers to understand the different development workflow to utilize the code review. Our team sizes range from ~3 to ~8 and haven't had any major problems.

They have an IRC channel which is usually pretty active, and I'm sure any questions or concerns you have can be brought up there.

We've been using it since ~Febuary 2015 and it's been a terrific addition to our development.

skyraider3• 11 years ago

GitLab Enterprise user here. GitLab's open-source policy is one of the major reasons we chose it (along with self-hosting and fairly modern, built-in continuous integration), but the GitLab community could use some additional design and documentation effort.

Things that almost make me want to switch back to GitHub:

- GitLab is really hard to look at. All of our devs are having trouble visually locating comments in diffs. We're always scrolling through the left-side menu looking for the issues tab. It's hard to visually differentiate between items like comments in merge requests. Our eyes just can't find and follow things. Even BitBucket looks better.

- GitLab-CI has poor documentation on runners, and a rather buggy test runner registration process that doesn't provide any debugging output and produces false positives quite often.

- GitLab-CI has no unconditional cleanup directive, like CircleCI does... but if you're re-using a test runner instead of tearing down the server each time, unconditional cleanup is the one thing you need. And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.

- CI is based on commit IDs. You can't run particular CI events on merge requests. For example, this means no way to run integration tests on merge requests.

- Typography could be improved. When you're looking at the issues page all day, this is quite noticeable.

- Slack integration is not great; it dumps links to "GitLab Enterprise Edition" instead of useful commit/changeset stuff like GitHub does.

If the community/GitLab can focus on putting on some of the design polish and service integration polish that GitHub has, GitLab would be a total winner for us, long-term.

jobvandervoort18• 11 years ago

Thanks for the feedback, we really appreciate it!

The quick reply to your comments is: we're working on almost all of it.

- GitLab is really hard to look at. All of our devs are having trouble visually locating comments in diffs. We're always scrolling through the left-side menu looking for the issues tab. It's hard to visually differentiate between items like comments in merge requests. Our eyes just can't find and follow things. Even BitBucket looks better.

We're working hard on this and focus more and more of our development capacity to this.

- GitLab-CI has poor documentation on runners, and a rather buggy test runner registration process that doesn't provide any debugging output and produces false positives quite often.

There are a lot of improvements coming in this field. Especially the integration and setup of runners is going to be easier. We're hoping to make this a zero-step setup thing. Same with documentation. Our new GitLab CI maintainer Kamil has been spending a lot of time on writing documentation.

- GitLab-CI has no unconditional cleanup directive, like CircleCI does... but if you're re-using a test runner instead of tearing down the server each time, unconditional cleanup is the one thing you need. And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.

This is interesting, I'm passing it onto Kamil.

- CI is based on commit IDs. You can't run particular CI events on merge requests. For example, this means no way to run integration tests on merge requests.

This is be interesting to look at. I'm not sure whether we have something like this in the planning, but I'm taking note.

- Typography could be improved. When you're looking at the issues page all day, this is quite noticeable.

We're worried about adding page load by including typefaces. We might change our minds on this. What OS are you using? Would Roboto work, for instance?

- Slack integration is not great; it dumps links to "GitLab Enterprise Edition" instead of useful commit/changeset stuff like GitHub does.

We welcome contributions to improve it. This is not a focus at the moment, but considering the popularity of Slack, we can definitely have a look at this.

skyraider3• 11 years ago

Super.. good to hear! Ideally the community can get a little more involved in design/UX too. I'm not sure if GitLab plans to set the tone there first - perhaps that's also on the roadmap.

Would Roboto work, for instance?

Maybe the typeface isn't so much the issue as the layout? On the issue view, comments and descriptions have different positioning and styling. Also, important information lives above the issue title, which is unexpected.

Being unable to trigger CI builds based on merge requests (which can dispatch a build for a commit ID, but you've probably already pushed that commit) is probably the most problematic for us at the moment.

Maybe it would be cool if GitLab came up with some basic design principles/goals and accepted contributions toward that end. I know we'd be interested in contributions here and there to improve workflow/UX.

fraserharris• 11 years ago

typefaces are cached by the browser. Done properly, you should see zero impact on page load past the first load.

paulojreis• 11 years ago

We're working hard on this and focus more and more of our development capacity to this.

No, no, no. :) It's not a development thing, it's a design thing. The good part is that your users are well-defined - developers; you could do a great job there, but don't allocate your developers to it. Hire or contract someone experienced in UX.

P.S. With a good UX work, you might end up not only bettering GitLab's layout but also discovering new, differentiating and truly useful (user-wise) features.

sytse33• 11 years ago

GitLab is really hard to look at. All of our devs are having trouble visually locating comments in diffs. We're always scrolling through the left-side menu looking for the issues tab. It's hard to visually differentiate between items like comments in merge requests. Our eyes just can't find and follow things. Even BitBucket looks better.

I agree out interface can be a lot better. Our first interaction engineer will start September 1 to improve it.

GitLab-CI has poor documentation on runners, and a rather buggy test runner registration process that doesn't provide any debugging output and produces false positives quite often.

There’s a lot of going on in this field. We are listening to people’s user cases and trying hard with the rest of community to extend documentation that will cover them. I agree the test runner registration should give better feedback if there are failures. False positives shouldn't happen, please create an issue if they do.

GitLab-CI has no unconditional cleanup directive, like CircleCI does... but if you're re-using a test runner instead of tearing down the server each time, unconditional cleanup is the one thing you need. And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.

Agree, we have that on our roadmap: allow to run commands in case of script failure.

CI is based on commit IDs. You can't run particular CI events on merge requests. For example, this means no way to run integration tests on merge requests.

I don't know what you mean exactly. Do you mean you want to test the code that will result after the merge instead of the commit in the feature branch? It would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated). BTW The new build trigger API (to be released in a month) is one of the upcoming features that will allow more build customisation.

skyraider3• 11 years ago

I don't know what you mean exactly. Do you mean you want to test the code that will result after the merge instead of the commit in the feature branch? It would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated). BTW The new build trigger API (to be released in a month) is one of the upcoming features that will allow more build customisation.

No, I want to trigger additional types of tests under two circumstances:

- When a merge request is created

- When additional commits are added to a branch for which a merge request exists

The utility is: I don't want to run integration tests if someone is just pushing to a feature branch - that takes up worker time. But I do want to run integration tests before that feature branch gets merged upstream. Achieving this by having everyone submit merge requests to an intermediate branch doesn't work, because we don't know the integration test result until after the merge to the intermediate branch is done, meaning developers might be trying to push a bunch of failing code to the same branch, just to get integration tests to run.

pbiggar3• 11 years ago

Question for you: as a GitLab Enterprise user, knwoing that GitLab has CI built-in, is there a situation in which you would buy CircleCI to go alongside it? Obviously we (we being CircleCI, founder here) have GitHub Enterprise support, and I wonder if we should build GitLab Enterprise support too.

kanzure3• 11 years ago

is there a situation in which you would buy CircleCI to go alongside it?

Well, we were using circleci for a while until the switch to gitlab-ci just recently. Biggest problem was that the circleci runners lose the local docker cache, which meant that unnecessary large chunks of time were spent redoing docker container builds, slowing everything down in our workflow. Note that we run unit tests in docker containers, and to speed things up it would be useful to run unit tests in parallel on multiple separate machines, in addition to preserving the local docker cache on each runner machine.

cname• 11 years ago

Even BitBucket looks better.

Slight tangent: I think Bitbucket looks nicer than GitHub in almost every way.

hobofan• 11 years ago

And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.

Why not? We are doing DinD testing on gitlab CI and it works great.

sytse33• 11 years ago

Glad to hear that.

mesozoic• 11 years ago

Add a search that isn't terrible and you'll solve most every complaint I have and hear from others about Gitlab.

sytse33• 11 years ago

What search are you talking about, in the issues or in the code?

r0naa4• 11 years ago

I am moving my stuff to a self-hosted GitLab.

If you are interested in knowing why:

- I personally find it a little bit irritating that Github wants to promote "open-source/free-software", but haven't open sourced their own tools/product.

- I was disappointed by the way Github handled some internal problems

- I don't trust Github anymore; I want to be in control of my data.

krupan• 11 years ago

"they/them" refers to someone other than gitlab?

r0naa4• 11 years ago

Thank you for pointing that out! they was referring to Github.

spike021• 11 years ago

Sounds like they're referring to GitHub.

exstudent28• 11 years ago

I also just canceled my Github subscription and moved all of my private repos to a self-hosted GitLab. I did this because I was very unhappy with the politics that GitHub recently decided it wanted to push.

The funny thing though, having my private repos on my own server just FEELS nice. I have total control over my projects. I wasn't worried about anyone "snooping" on them but there's a subtle psychological change when you know your code is on your sever and no one other than you has admin access.

I moved for political reasons, but found the intangible benefits of being the "master of my domain" were a great unintended side-effect.

MichaelGG2• 11 years ago

Don't sell this position short as a mere "political reason". Github has decided that rationality and critical thinking take a back seat. This is a vastly damaging attitude that hurts the world. Providing any encouragement to unclear thinking is a vile thing to do. This is far worse than environmentally unfriendly attitudes; it's far more important than even open source.

hk__24• 11 years ago

I personally find it a little bit irritating that Github wants to promote "open-source/free-software", but haven't open sourced their own tools/product.

They have 100+ open-source repos: https://github.com/github They also contribute a lot back to Git.

r0naa4• 11 years ago

I take that back then, I was misinformed

avinassh• 11 years ago

How does the licensing works? Can anyone explain me? [0]

This software and associated documentation files (the "Software") can only be used with a valid GitLab subscription for the correct number of users. You are free to modify this Software and publish patches. It is forbidden to copy, merge, publish, distribute, sublicense, and/or sell copies of the Software.

Isn't the third line contradicting with the fourth or have I misunderstood?

[0] https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE

superuser2• 11 years ago

A patch - literally a file generated by "diff" - only incidentally contains the original code, mostly your new functions and modifications. So you can't distrbute a patched version of the software, only the patch itself.

sytse33• 11 years ago

Exactly, that is how I meant that.

kevinSuttle• 11 years ago

If only this post was written by GitHub.

btashton• 11 years ago

I set up gitlab internally a couple years ago and it has been a pleasure. One big thing I fight is we have a lot of micro services that we want to have the same label set for and would like to manage against the same milestones. It would be really nice if label sets and milestones could be created for a group.

sytse33• 11 years ago

Feel free to contribute that feature. I would love to create a milestone for all projects in a group in one go. Please be aware that if you name the project milestones the same you can use them to aggregate issues across multiple project in one view.

brugidou• 11 years ago

As a Gitlab CE user and part of a large company using Gerrit for code reviews I am really surprised that Gitlab does not try to emulate a bit more the various enterprise grade Gerrit features available such as full side-by-side diffs with key shortcuts, review history to easily see what changed since the last time you reviewed the merge request (even with rebased commits), +1/+2 rules, custom plugins available... Etc.

I know that Gitlab EE has some features like the merge request rebase, but I don't know how a large company using gerrit could be convinced to switch to reviews in Gitlab

sytse33• 11 years ago

We would love to add features like that. We have side-by-side diffs and shortcuts, but maybe not what you want. New commits are shown in the discussion (doesn't work with rebasing). You can have approvers for merge requests https://about.gitlab.com/2015/06/16/feature-highlight-approv... and we support project services http://doc.gitlab.com/ce/integration/README.html

Anyway, I'm sure that there are still things missing and you are very welcome to add them to CE or EE. We had large companies switch from Gerrit but we hope to keep adding features that people currently miss.

chriswarbo• 11 years ago

Since gitlab closed gitorious.org, I've switched to serving all of my repos as static files generated from git2html, and accepting patches by email. Once burned...

sytse33• 11 years ago

Just for your information, we had a 'one-click' import from Gitorious to GitLab.com. It will come online again after the internet archive work is done.

swah• 11 years ago

Everything should be open. Its almost immoral to sell software nowadays. No wonder so many people are flying to mobile...

Almost Everything We Do Will Be Open

Related Stories