GitLab 8.0 released with new looks and integrated CI(about.gitlab.com)
about.gitlab.com
GitLab 8.0 released with new looks and integrated CI
https://about.gitlab.com/2015/09/22/gitlab-8-0-released/
138 comments
Thanks for your suggestion.
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 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.
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.
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.
Cool, hope you like GitLab when you try it.
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)
We're working on it, among other things.
Concrete suggestions more than welcome on feedback.gitlab.com or here.
Concrete suggestions more than welcome on feedback.gitlab.com or here.
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"
- 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"
Thank you for the suggestions. One thing that is under development is filtering by more than one label https://gitlab.com/gitlab-org/gitlab-ce/issues/989 Many of the other items make sense as well.
Congrats on the release! It looks amazing! We've been using GitLab for a little while now and love all the updates that have been coming out recently.
Doing the upgrade now though and have run into an issue with the rake command backup:show_secrets. ("Don't know how to build task...") Any ideas?
Doing the upgrade now though and have run into an issue with the rake command backup:show_secrets. ("Don't know how to build task...") Any ideas?
See https://gitlab.com/gitlab-org/gitlab-ce/issues/2660
Documentation seems to be ahead of current GitLab release. This failing task will be included in a following patch release, very soon.
Documentation seems to be ahead of current GitLab release. This failing task will be included in a following patch release, very soon.
Thanks! That's nice to hear.
Can you create an issue with some more information (such as: what command did you run, what was the exact output, etc)?
If you're a subscriber, please email support :)
Can you create an issue with some more information (such as: what command did you run, what was the exact output, etc)?
If you're a subscriber, please email support :)
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".
Thanks cevn, fixed with https://gitlab.com/gitlab-com/www-gitlab-com/commit/e23e5280...
Updating broke my ci builds, :(
edit: following advice in this issue worked for me - https://gitlab.com/gitlab-org/omnibus-gitlab/issues/804
edit: following advice in this issue worked for me - https://gitlab.com/gitlab-org/omnibus-gitlab/issues/804
It doesn't look like there is any way to have per-receive hooks anymore: https://gitlab.com/gitlab-org/gitlab-ee/issues/26
Any chance of getting packages for Ubuntu 15.04?
There appears to be an open issue at https://gitlab.com/gitlab-org/gitlab-ce/issues/2160
There appears to be an open issue at https://gitlab.com/gitlab-org/gitlab-ce/issues/2160
Latest build should work, see https://gitlab.com/gitlab-org/gitlab-ce/issues/2160
I tried following the instructions here https://about.gitlab.com/downloads/ but that doesnt work since there is no vivid package.
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)."
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.
Awesome. Integrated CI is probably the move wich will make me move from gitHub.
Cool! Glad to hear you like the CI integration, we'll continue to improve it https://gitlab.com/gitlab-org/gitlab-ce/issues/2594
I've flaslessly updated today. Looks awesome. I'm really grateful for such a good software product. Thanks for GitLab!
Glad to hear that, thanks for using GitLab!
Easily the biggest change for GitLab to date. CI is now built-in and it's all easier on the eyes.
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.
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.
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.
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.
Understandable, thanks! Not sure when we will be updating, but will be in touch should we have any tricky issues migrating.
Great. Consider sending your upgrade plan ahead of time if there is anything tricky. We're happy to check it.
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.
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.
The text was always there, but is collapsed by choice and on small screens.
It's either Activity or Readme now. I don't think it'd be very hard to add Files to that and don't have major problems with it.
Consider sending a MR or creating an issue [0] to discuss this further.
0: https://gitlab.com/gitlab-org/gitlab-ce/issues
It's either Activity or Readme now. I don't think it'd be very hard to add Files to that and don't have major problems with it.
Consider sending a MR or creating an issue [0] to discuss this further.
0: https://gitlab.com/gitlab-org/gitlab-ce/issues
I love this idea and created an issue for it https://gitlab.com/gitlab-org/gitlab-ce/issues/2655
When will the Sandstorm package be updated? Will it support CI?
https://apps.sandstorm.io/app/zx9d3pt0fjh4uqrprjftgpqfwgzp6y...
https://apps.sandstorm.io/app/zx9d3pt0fjh4uqrprjftgpqfwgzp6y...
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.
Documentation on Runners: http://doc.gitlab.com/ci/runners/README.html
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.
Documentation on Runners: http://doc.gitlab.com/ci/runners/README.html
[deleted]
The Mattermost preview screenshot is an odd choice - have a read of the conversation.
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.
On the GitLab Mattermost page (https://gitlab.com/gitlab-org/gitlab-mattermost) there was a subtitle describing this, but we could have made it more clear in the screenshot itself.
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.
On the GitLab Mattermost page (https://gitlab.com/gitlab-org/gitlab-mattermost) there was a subtitle describing this, but we could have made it more clear in the screenshot itself.
Got it from the Mattermost Beta1 announcement. Think it's inappropriate?
Just seems weird for the conversation to be about how someone refuses to switch to it, that's all. :)
> about how someone refuses to switch to it
Keep reading.
Keep reading.
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.
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?
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?
To download for the Raspberry Pi 2 just go to the download page and select that option https://about.gitlab.com/downloads/
We switched to building with Gitlab-CI and haven't looked back. A big bonus over Jenkins is the lack of Java.
"If you runners overload your CI system now both go down" Isn't that a bit worrisome?
Where does it say that?
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.
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.
I feel much better about it now. Thanks.
I read it under "advantages and disadvantages".
I read it under "advantages and disadvantages".
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.
[deleted]
The killer feature (for me) would be if GitLab supported the GitHub API (even if just a subset).
In what way?
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.
Interesting idea.
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.
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.
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.
It should work!
I double checked and upgraded my personal instance and it works here. Did apt-get update complete succesfully?
Repo is here for double checking: https://packages.gitlab.com/gitlab/gitlab-ce
I double checked and upgraded my personal instance and it works here. Did apt-get update complete succesfully?
Repo is here for double checking: https://packages.gitlab.com/gitlab/gitlab-ce
It looks like everything is working properly, this is what I get if you are interested: https://gist.github.com/anonymous/4792e387f33155308ddf
I think our package repo is not in your sources.list!
To add it: `curl https://packages.gitlab.com/install/repositories/gitlab/gitl... | sudo bash`
To add it: `curl https://packages.gitlab.com/install/repositories/gitlab/gitl... | sudo bash`
Wow that's not terrifying advice at all. /sarcasm
If you expect someone to run their own git & ci server, is it so hard to give them a couple of dot-point instructions:
- create a .list file with these two lines: <blah>
- add the GPG key for Apt
- run aptitude/apt-get update
Sure enough, you're already listed on curl|sh (http://curlpipesh.tumblr.com), which also includes a link to the https://packages.gitlab.com/gitlab/gitlab-ce/install page which has a "manual" tab.
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!?
If you expect someone to run their own git & ci server, is it so hard to give them a couple of dot-point instructions:
- create a .list file with these two lines: <blah>
- add the GPG key for Apt
- run aptitude/apt-get update
Sure enough, you're already listed on curl|sh (http://curlpipesh.tumblr.com), which also includes a link to the https://packages.gitlab.com/gitlab/gitlab-ce/install page which has a "manual" tab.
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!?
Hi:
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.
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.
Sending the hostname is default Packagecloud.io behaviour.
> Sending the hostname is default Packagecloud.io behaviour
Your own download page states:
We recommend you set the name to the fqdn of the target node (the value of hostname -f on linux), but you can set it to whatever you want
If your company is recommending something, shouldn't you have a good reason why?
Your own download page states:
We recommend you set the name to the fqdn of the target node (the value of hostname -f on linux), but you can set it to whatever you want
If your company is recommending something, shouldn't you have a good reason why?
Can you link to the page where you found this? I can't find it on https://about.gitlab.com/downloads/#debian8
This seems like setup instructions for GitLab and I think it is unrelated.
This seems like setup instructions for GitLab and I think it is unrelated.
The page I linked above: https://packages.gitlab.com/gitlab/gitlab-ce/install
Click the "Manual" tab, last paragraph of the 'deb' section.
Click the "Manual" tab, last paragraph of the 'deb' section.
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.
Shipping in 1.0.23
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.
Shipping in 1.0.23
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).
@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).
Thanks!
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.
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.
Once we'd add "new issue by email", you could do this with a workaround:
You can mention groups in GitLab. Create a group translators, devs, etc and then mention them:
"@translators can you have a look at this?"
Would then create a new issue and notify all members in the @translators group.
Would that suffice? How else?
You can mention groups in GitLab. Create a group translators, devs, etc and then mention them:
"@translators can you have a look at this?"
Would then create a new issue and notify all members in the @translators group.
Would that suffice? How else?
> Would that suffice? How else?
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:
https://www.winehq.org/forums
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.
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:
https://www.winehq.org/forums
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 ;)
Eat your own dog food, as they say. :)
Eat your own dog food, as they say. :)
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.
Looks promising. Maybe even will try it out.
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
Try it on GitLab.com for free (no limits).
It seems to be down at the moment?
It's not at the time of writing.
http://status.gitlab.com/
http://status.gitlab.com/
"Tweets by @git_lab" -> "Account suspended"
That's a bug in the website.
The correct and active account is @gitlabstatus
The correct and active account is @gitlabstatus
Indeed, we'll update the status page to reflect this https://gitlab.com/gitlab-org/status-gitlab-com/commit/1d4cf...
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 :)
Thanks, that's nice to hear. Love to hear your feedback.
This is where I shamelessly tell you that we're hiring for almost any position.
This is where I shamelessly tell you that we're hiring for almost any position.
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?
We'll consider all great people =)
That timezone would be especially great for a service engineer since we offer 24/7 support and don't have people in that region yet :)
Have you looked at other products?
Can we run gitlab 8.0 without CI?
You can just not use it. There will be a few links in the UI, but it will not cost you anything.
Note that you can still integrate with your current CI.
Note that you can still integrate with your current CI.
And the links will mostly be in the settings menu's. In GitLab 8.1 there should be zero links added to dashboard/group/project navigation https://gitlab.com/gitlab-org/gitlab-ce/issues/2594
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.
Looks good!
One question though, clicking on any of the files on https://gitlab.com/gitlab-org/gitlab-ce/tree/master/config takes at least 10s to open, is it because the site is being hammered right now?
One question though, clicking on any of the files on https://gitlab.com/gitlab-org/gitlab-ce/tree/master/config takes at least 10s to open, is it because the site is being hammered right now?
Yes. We went from 3 to 50 c4.4xlarge nodes in the past few months and are working hard to keep up with the demand of the growth.
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.
Good to hear!
> I wish you can view people's activity calendar even if the projects are private.
That would show you private information, which is not what we want.
> I wish you can view people's activity calendar even if the projects are private.
That would show you private information, which is not what we want.
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:
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)
(Username) made X(number) of commits to private repo/s today.I understand your reasoning, and realise that this is something potential employers look at.
That said, I don't think amount of activity or nr of commits should be indicative of anything for any good employer.
I also don't know if this is enough of an argument to change this in GitLab. I prefer to choose the privacy-preferable option.
That said, I don't think amount of activity or nr of commits should be indicative of anything for any good employer.
I also don't know if this is enough of an argument to change this in GitLab. I prefer to choose the privacy-preferable option.
If you want this maybe you can ask the applicant to take a screen-dump/print-to-pdf of the information you want.
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.
Even that would be leaking private information, no matter how minor it seems.
Good to hear you like the integration of CI.
Good to hear you like the integration of CI.
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
So make it an optional feature for people to enable on their own accounts?
The dashboard doesn't show an activity feed anymore, just a giant list of projects? That's pretty lame.
Click 'Activity' for the Activity feed. We welcome feedback and contributions to improve this further.
This first step was necessary to clean up clutter in the UI.
This first step was necessary to clean up clutter in the UI.
Thanks for the help, was just poking around preferences to see if I could enable it.
[deleted]
Nice!
At work we use self-hosted GitLab for everything.
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.
At work we use self-hosted GitLab for everything.
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.
Gitlab or Bitbucket aren't going to handle deploys for you.
You need gitlab-ci with the continuous deployment option.
For others: Fabric is a python project similar to Capistrano.
You need gitlab-ci with the continuous deployment option.
For others: Fabric is a python project similar to Capistrano.
[deleted]
Why Fabric over GitLab?
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.
> GitLab.com offers free unlimited (private) repositories and unlimited collaborators, please sign up or in on the right.
[deleted]
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.
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.
This is not the place to post this.
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.
Your skills may be excellent but if you don't have anything complex to prove it with they can't figure that out.
You're right. And I don't think that my skills are great.
But there are many ways to say 'you are not good for this job'
that's all
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
[deleted]
time for me to upgrade!!
Any free alternative to GitLab?
Gogs seems to be an option but it seems to be missing a very important feature of code review.
Gogs seems to be an option but it seems to be missing a very important feature of code review.
GitLab is already free, in both senses.
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).
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.
I really like phabricator (http://phabricator.org/) with differential (https://phacility.com/phabricator/differential/)
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.