Almost Everything We Do Will Be Open • Hacker News Board

Re: Almost Everything We Do Will Be Open

#121

Post by skyraider » Fri, Aug 07, 2015, 6:14 PM UTC

sytse wrote: post #119

skyraider wrote: post #72

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 di…

> 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…

> 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.

Re: Almost Everything We Do Will Be Open

#122

Post by klapinat0r » Fri, Aug 07, 2015, 6:15 PM UTC

aidenn0 wrote: post #114

klapinat0r wrote: post #84

Earlier quoted context omitted.

Which tools are you talking about?

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

Ah, thank you.

Re: Almost Everything We Do Will Be Open

#123

Post by kanzure » Fri, Aug 07, 2015, 6:26 PM UTC

skyraider wrote: post #121

sytse wrote: post #119

Earlier quoted context omitted.

> 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…

> 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 featu…

> But I do want to run integration tests before that feature branch gets merged upstream.

Specifically, the integration tests should run against the version of the source code in the feature branch that the merge request is about. The target branch can be merged into the feature branch to have full coverage of the post-merge status, so the target branch's importance is really minimal here.

> Yes, 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).

Actually no, that's not what I was trying to get at. The tests just have to run against the version of the source code in the feature branch. If the integration tests need to cover anything else, it should be inserted into the feature branch manually. Stale branches are their own problem and are quite common, independent of CI-related testing. Running unit tests all the time is fine, but it would be nice if special additional tests can be triggered only for new merge requests and for updated merge request source branches but not feature branch pushes unassociated with merge requests.

Re: Almost Everything We Do Will Be Open

#124

Post by techpeace » Fri, Aug 07, 2015, 6:30 PM UTC

fraserharris wrote: post #105

jobvandervoort wrote: post #75

Earlier quoted context omitted.

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 an…

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

+1

Also worth checking out: https://www.filamentgroup.com/lab/font-events.html

Re: Almost Everything We Do Will Be Open

#125

Post by antsar » Fri, Aug 07, 2015, 6:33 PM UTC

nadams wrote: post #116

jobvandervoort wrote: post #53

Earlier quoted context omitted.

As KingMob pointed out, I linked to our proprietary license of GitLab Enterprise Edition. GitLab Community Edition is licensed under the MIT Expat license: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/LICENSE

It doesn't matter which product it was for - it still seems contradictory. It says I can distribute patches but then it says I can't. I wasn't joking when telling you that you should get a lawyer on the phone. I've seen a number of people try to write their own software license - and fail miserably. It really has me kind of worried that your response wasn't "we did consult with a lawyer when creating that license".

In what way does it seem contradictory? It seems to allow one to write and publish patches, while disallowing the redistribution/resale of the original code.

Re: Almost Everything We Do Will Be Open

#126

Post by sytse » Fri, Aug 07, 2015, 6:38 PM UTC

skyraider wrote: post #121

sytse wrote: post #119

Earlier quoted context omitted.

> 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…

> 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 featu…

In general we recommend to run tests all the time. Machines are cheap compared to developers and you can add as many runners as you want.

What you can also do is use project or system hooks to trigger CI via the new build API that will be available on August 22.

Another option is to skip builds, you can just add [skip ci] to your commit message, and next build will be skipped.

Re: Almost Everything We Do Will Be Open

#127

Post by pbiggar » Fri, Aug 07, 2015, 6:44 PM UTC

skyraider wrote: post #72

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 di…

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.

Re: Almost Everything We Do Will Be Open

#128

Post by hk__2 » Fri, Aug 07, 2015, 6:47 PM UTC

kasbah wrote: post #33

nadams wrote: post #25

Earlier quoted context omitted.

Why would Microsoft buy github? They have their own.

Why did Google buy YouTube when they have Google Video?

YouTube was <1 year old when it was bought; GitHub is 7 years old.

Re: Almost Everything We Do Will Be Open

#129

Post by hk__2 » Fri, Aug 07, 2015, 6:52 PM UTC

zxcvcxz wrote: post #19

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…

> 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.

Re: Almost Everything We Do Will Be Open

#130

Post by kanzure » Fri, Aug 07, 2015, 6:54 PM UTC

pbiggar wrote: post #127

skyraider wrote: post #72

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 di…

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.

> 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.