This looks awesome! I've been playing with it today and have setup a docker instance for doing Android builds on the same (Linux) machine that I've installed Gitlab on. I'm having trouble setting up Xcode/iOS builds on a Mac Mini over ssh and I don't see any specific documentation on that. Is that something you can point me to?
With this release is it necessary to migrate to the built in CI or can we still point at a different gitlab-CI server? We have gitlab running privately in a VPC on AWS but have gitlab-CI running locally (dedicated local server for the manager and runners) so, essentially, merging the two isn't going to be trivial.
No. We wouldn't be able to support and keep development going while supporting two different CI apps.
Only the coordinator moves, so in theory you'd be able to use the same runners.
It's not a trivial migration, we know. That is why we do this with a major release. We're also continuously improving the documentation for this migration.
Our customers can reach out for online support, of course.
Congratulations GitLab team. I've been really thrilled to see the project evolve and I'm super excited to see this update. And I don't even use GitLab :)
@jobvo I remember leaving extremely lengthy UX and feature feedback here on HN a few weeks back - Email followup never happened. I hope you guys considered working on mailing list support in the style of a Google Groups / Discourse UI. It'd go really well with the Mattermost integration (which I'm also really excited to see).
I do still owe you a folllowup! Wanted to push this out first before weaving in new suggestions and feedback. My apologies.
You can now reply to notifications, which already gives you some of that functionality. We're interested in expanding this.
We'll add a feature that allows you to email GitLab to create a new issue in a future release. Shouldn't be far off, now that we laid the groundwork for receiving email.
That sounds like some good groundwork. Do you have plans to expand this to a proper ML system? Eg. I have a project and want to coordinate one list for translators, one list for devs, and one list for user support.
I think it's a great feature and very useful for smaller projects especially, but it doesn't replace mailing lists for larger ones.
In open source projects especially, it's standard procedure to create one or more topical mailing lists with archives. Take a look at the Wine lists for example - active lists with forum mirroring:
This is something that really improves some workflows - especially FOSS projects with a lot of outside contributions. Email is super friendly to newcomers to a project, and forums/archives let you get a feel for the general social tone as well as look at older issues matching your own. I don't think you can just replace this with a tracker.
We use mailinglists ourselves with https://groups.google.com/forum/#!forum/gitlabhq (hosted outside of GitLab) but we think the best thing for newcomers is a Slack/Gitter like forum. We've added Mattermost to the GitLab Omnibus packages and we're working with Rocket Chat. When that is done it will be easy to give each project its own room or something like that. What do you think?
I think if you yourself use mailing lists, you understand when and why mailing lists can't be replaced by slack/gitter and by extension you understand my point ;)
We certainly try to use our own products as much as possible. We see that the chat is more popular. Integrating a mailinglist is not easy and we prefer to spend time on chat instead.
I really wish Gitlab could create two entities. Gitlab.org and Gitlab.com
Much like how Wordpress is run. Gitlab.com's profits and revenue will be used to fund the continue development of Gitlab.org
For now the Gitlab.org part ( Or the open source development of Gitlab ) is fine.
But Gitlab.com seems like a after thought. It should runs like Github, where you actually paid for Storage, Bandwidth etc for a price. Rather then the current price model which is for support only. This makes me feel Gitlab.com is more like a showcase of Gitlab, rather then a properly run services.
Some will bound to come to me, why dont you buy a VPS and set it yourself? Because i dont want the hassle. Should some day Gitlab close or company policy changes i will know there is always a open sources version where you can host it back on site.
It will also means those communities, or organization who refuse to host their code on Github due to lock in reason ( like Ruby ) can switch to Gitlab without ( ideally speaking ) the same hesitation.
I can assure you that our GitLab.com SaaS service is not an afterthought. It is growing so fast that we do have trouble keeping up with that, but we're hiring more people and things are looking up.
BTW We actually used .org and .com in the past for the community and the for-profit sites. We combined everything on .com because that removed a lot of duplication in announcements, information and many other things.
I think I like the menu UI improvements in the screenshots. Those tiny symbols were a major pain for any new user, and it's good to see words next to them now.
But is it possible yet to make the project files show up in the default view for projects? Many user interactions with a project don't go beyond browsing the files, and I wish I could enable GH-style default views.
I've been following gitlab for some time now. Both as a product and a company. Not only is it an amazing product, but from everything I've read they've made a really interesting culture. Would actually love to work for the company. Congrats to the team on shipping this. I'll be giving it a whirl soon :)
Nice! Not sure if you are still looking at the the thread, I know Gitlab allows for fully remote (yep, I've read the manifesto :D ) but would you be ok with someone working from Sri Lanka? Time zone differences being main concern?
GitLab could function (at least somewhat) as a drop-in replacement for GitHub, as existing GitHub API client libraries could point to GitLab instead with minimal/zero modification.
I'm afraid it would cause us to follow their changes, which makes it a brittle strategy that would prevent us from innovating. We prefer people to adopt GitLab itself.
You could provide an adapter API which translates Github-like requests to your API. If you want to use specific GitLab API features, developers use the "native" GitLab API.
The messaging integration certainly looks really good, we're trying out Let's Chat, but development is kinda slow (and we don't have the time to contribute). How does GitLab CI compare to Jenkins? Will I be able to substitute it for simple and complex projects?
Is there a slender version of GitLab for small computers like the RaspberryPi? All of the dependencies kinda hog/slow it down, and I don't really need realtime performance. I've grown fond of the interface (at work), and would like to use it for my hobby projects.
GitLab CI should be able to replace Jenkins. Obviously, it doesn't have the maturity of Jenkins or the plugin ecosystem, but it's flexible runner system, easy configuration with .gitlab-ci.yml and integration with GitLab make it quite powerful.
You can already have multiple, parallel builds, builds on success/failure, trigger builds and thus create pipelines. We don't support build artifacts yet, but you can circumvent this by using something like S3 for output. We'll add this in the future as well.
GitLab should run just fine on Raspberry Pi 2. Do you have any data on slow down?
Mattermost team here. Sorry if the screenshot is confusing.
The text of the screenshot was actually written in Slack, and the goal of the screenshot was to demonstrate the Slack Import feature to GitLab Mattermost.
Wow, this looks really nice! Are there any plans to expand the CI? The markup looks mostly job oriented, so I think most of the semantics would seem to need to be captured in scripts. For example, building across multiple operating systems. Unless I'm mistaken, I'd have to have the hosts available via SSH, probably copy a script(s), and then call it, etc...
You can already define multiple jobs in .gitlab-ci.yml and use labels to assign them to runners (#debian, #osx etc.). We use GitLab CI to build our Omnibus packages and that is a multiple operating system affair (including Raspbian for the Raspberry Pi 2).
Thanks, I appreciate the response. I started taking a look through the documentation and the CI looks pretty robust. I might try to set GitLab up at home soon.
I currently use hosted travis-ci for personal projects, which is nice since I don't have to worry about infrastructure, but it means there are things that can't be done with it. Generally stuff they haven't anticipated is verboten.
Now I need a private repo (personal project) to deploy on my VPS, any opinions about GitLab vs Bitbucket for this use case? Speed, stability? I'm probably going to use Fabric this time.
I mean GitLab/Bitbucket just for the private git repo. Fabric for tasks, atomic deploy (I think that's the word), etc. I'm only experienced with self-hosted, never used their services.
> GitLab.com offers free unlimited (private) repositories and unlimited collaborators, please sign up or in on the right.
Wow nice release, it's come miles since I used it years ago, very cool! The only thing I'm missing at this point to make it perfect is a more advanced issue tracker (coming from Phabricator)
Our use case might be fairly specific, i don't know how others are using bugtrackers, but this is how and what we use in our bugtracker:
- Hooks (getting notified of changes in issues in http scripts)
- Api to modify them (couldn't find if gitlab has that), we use hooks, apis and custom fields to create issues from our forum and notify customers when one is closed/reopened.
- Custom fields (priority, severity, to store where an issue came from, like from our forum, from support, what the customers name is if any, if it's waiting, on what specific input, if it going to need documentation, and if so, what concerns there are)
- Custom open/close status like "Needs spec, specing, docs", close: "spam", "not fixable, testcase error" etc
- Sorting by more than 1 thing at a time, like due milestone, priority, severity)
- Filtering by pretty much all fields/custom fields like finding issues with specific open or closed states, specific categories, specific assignments
- Predefined filter/sorting queries (global/per user) so we'd have an "All issues assigned by me", "All new issues"
Looks good! One small typo: On the Pricing page https://about.gitlab.com/pricing/, instead of " Next-business day support" it should be "Next business day support".
I did not follow the steps listed here - https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/inst... since the text pretty strongly discourages a build from source. Specifically this line "Since an installation from source is a lot of work and error prone we strongly recommend the fast and reliable Omnibus package installation (deb/rpm)."
Thats the same ticket that I linked to and as far as I can see it does not provide any more information about the latest build. Perhaps you meant to include another link in your comment in the ticket?
Sorry, I missed that you also linked to that ticket. Anyway, did you try to install and it failed on a fresh machine? In that case I can reopen the issue.
Not up to us, but I'm sure it will. We have an amazing community of organisations, users, contributors that are often very fast adopting our new releases.
It will support CI. GitLab CI works with a central coordinator (now inside of GitLab) and external Runners.
The Runner can be anything outside of the instance. This makes it easy to configure them to your liking and doesn't slow down you GitLab instance while builds are running.
Will it take some time to propagate? Using the omnibus AMI on ubuntu and doing sudo apt-get update / sudo apt-get install gitlab-ce doesn't pull the update.
Even with "manual" selected, you still insist that people should make a http request to your server, to generate a .list file, even though the only variables are local variables, which you send as part of the request anyway: distro ID (e.g. Debian, Ubuntu, etc) and release codename (Wheezy, Jessie, etc).
The most ominous thing to me is that you send the result of `hostname -f` to your server. Even bigger WHY!?
I built packagecloud, which is what GitLab uses for hosting packages.
Getting a package repository installed securely is quite a bit more difficult than it seems, but I agree that our Manual install instructions should be simplified and improved. I'll see what I can do about making them better.
As far as the hostname goes: we used it simply because its a unique identifier for the machine, but really anything could be used (like a MAC address or whatever). This is used because private repositories have tokens issued against a unique identifier, so a machine reinstalling a repo won't generate a new read token. I'll add a comment to the bash script explaining this, and consider adding an override in the future so that users can specify another identifier of their choice instead.
This is why a request to the server is required: it generates a read token server side which is then implanted into the APT repository configuration for the local machine so that the local machine can access the repo.
We want to make it as easy and fast as possible to start with GitLab, hence the curl from https. But feel free to send a merge request to improve the download page with the instructions you would like to see and we can discuss.
Sending the hostname is default Packagecloud.io behaviour.
This is the default download page of PackageCloud. The reason for this is probably that most of the time PackageCloud requires credentials to download packages. But I'll ask the author.
Joe of PackageCloud was kind enough to change the code so that an id will be send back, not the hostname.
The changes:
1.) Renamed hostname to unique_id everywhere, and added more prose
around replacing unique_id with any unique identifier.
2.) Removed the unique_id code from install scripts for public repos
(still exists in private repos)
3.) Modified the manual install instructions to be easier to follow,
and not require a curl to the server for public repos.
4.) Added mirroring instructions for both YUM and APT.
This patch is a game changer. Wow!
I really love gitlab, however one thing: I wish you can view people's activity calendar even if the projects are private.
I'm going to agree with Taesu here, and elaborate a bit.
Some potential employers these days are looking at interviewees commit calendars on GitHub; and this is something I can provide to show I'm a very productive coder.
"Go look at my commit history; see I sure do a lot of coding."
So I agree with you about keeping the information private, but I think this could be solved by doing something like this.
- Public Activity:
Display detailed information. Commit number, message, repo. (What you are showing today)
- Private Activity;
(Username) made X(number) of commits to private repo/s today.
maybe, just notification (light green to dark green) to indicate the commits. I just wish to show my potential employeers that I work privately in gitlab instead of github. regardless, this integrated CI inhouse is defiantely something that I really really looked for.
Agreed, it's leaking private information. It would be awesome if the user could opt in to that leak. I feel the same way about Github - I wish I'd be able to show my full history (top) on my public profile page (bottom) http://take.ms/qiBMm
Shameless plug, if you have composehub installed, you can just do "ch run gitlab" and it will download and run gitlab for you on your machine. You just need docker installed on your machine https://composehub.com/package/gitlab
How do we point to an existing CI environment? In 7.14 we used GitLab CI service and pointed it to the Jenkins project URL. With the CI integration it appears those options have been removed.
This is my experience in GitLab application as developer.
After my application I received an email like this:
The code you linked to is all quite basic, could you give me an example of some more complex
Ruby code worked on, so that I can make an assessment of your ability in that regard.
There are many developers better that me, but I never say to other developers during an hiring process ' your code is all quite basic', it is not elegant.
I have commits in ruby on rails framework but sure there are many developers better than me!
But understand under the wood of a complex framework like rails is not very simple, for me :)
Anyway I send some part of my last works and that was the response:
I have reviewed your application and regret to inform you that it has not been selected for further
consideration, because I don't think your Ruby/Rails skill is currently at the level that we
require.
Yes probably it's sure but maybe 'your skill do not fit with our requirements' or ' we're looking for an more experienced developer' ?
I think that in two mails like that, there is a lot of arrogance that not match with open source mentality.
P.S.
I think that gitlab is a great product, it's just my experience in application process.
I’ve handled your application. I’m sorry you felt that you were not treated well during your application to GitLab.
We set a very high level for our developers and do our best to maintain this. We try to communicate clearly to our applicants on what grounds we refuse their application. How would you prefer this to be handled instead?
Arrogance or honesty? I frankly prefer this direct response that gives you direct addressable things you can work on improving if you want to re-apply.
Your skills may be excellent but if you don't have anything complex to prove it with they can't figure that out.
This is not appropriate post about the 8.0 announcement. But I'll give you this: any project with a CLA and a dual-version open / proprietary thing is not 100% in-line with ideal Open Source or Free Software values. I'll also give GitLab this: they've gone further than most would expect when pushed and have made sure their JavaScript is all Free/Libre/Open, and good for them. They could be better and they could be worse.
There are many open source software that live in ambiguity, maybe for business/sponsorship reasons. I can figure out how it is hard to develop an open source project that needs a lot effort.
But there is a base that you can lose, in open source company, the respect to people that send to you a Resumè, or want collaborate in your project
It should say that they don't both go down! Runners are fully external to GitLab and GitLab CI. This means they will never interfere with GitLab's functioning.
You should not host a Runner on a GitLab instance. It was not intended like that and in the documentation we explicitly tell you to not do this.
Ahh I know where that came from.
The runners push the build results back to the coordinator (which is now included in gitlab).
So in theory, if you have a large number of runners and a very large number of concurrent builds, it could slow down gitlab a little bit.
But the numbers you need to reach this are pretty high.
At my last job I left last week, we were looking for an alternative to the old GitHub/Jenkins setup, tried Stash/Bamboo for a while, but eventually settled on GitLab and GitLab CI (7.1x, with the Ruby-based CI runners) because the integrations with other services were already so mature. It took minimal customization to our Hubot to recreate our devops scripts and was really more of a drop-in replacement for what our Ruby shop needed. Although we eventually bought an Enterprise Edition license, we were still running the Community Edition (mostly because I left and just ran out of time to migrate), but were hardly lacking anything in the choice to stay on community until other more pressing migrations are dealt with (thanks first-gen Rackspace cloud).
If you're looking to centralize your devops infrastructure, I'd highly recommend GitLab over anything else unless you have a specific use case that GitLab isn't trying to solve (CF's BOSH, or a tighter integration with Atlasssian in a JVM shop for example).
Thank you very much for sharing this! By the way, we just made a CF tile for GitLab, we'll announce it later. But it is build with GitLab CI and Bosh. So if you have any questions about that please ask support, we'll be happy to give you some bang for your subscription bucks.
We also removed the satellites, on which we used to do certain git operations. This frees up space, but also makes merges must more stable and faster.
Let us know if you have any questions or comments.