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.
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?
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.
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.
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.
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?
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.
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.
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!?
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.
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.
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.
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
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?
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 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.
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
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.
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.
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.
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.
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?
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
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.
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".
138 comments
[ 4.7 ms ] story [ 221 ms ] threadWe 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.
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.
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.
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
https://apps.sandstorm.io/app/zx9d3pt0fjh4uqrprjftgpqfwgzp6y...
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
Keep reading.
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.
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.
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?
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 read it under "advantages and disadvantages".
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 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
To add it: `curl https://packages.gitlab.com/install/repositories/gitlab/gitl... | sudo bash`
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!?
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?
This seems like setup instructions for GitLab and I think it is unrelated.
Click the "Manual" tab, last paragraph of the 'deb' section.
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
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.
@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.
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?
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.
Eat your own dog food, as they say. :)
http://status.gitlab.com/
The correct and active account is @gitlabstatus
This is where I shamelessly tell you that we're hiring for almost any position.
Note that you can still integrate with your current CI.
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?
> 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.
Good to hear you like the integration of CI.
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:
- Private Activity;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.
This first step was necessary to clean up clutter in the UI.
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.com offers free unlimited (private) repositories and unlimited collaborators, please sign up or in on the right.
You need gitlab-ci with the continuous deployment option.
For others: Fabric is a python project similar to Capistrano.
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.
Your skills may be excellent but if you don't have anything complex to prove it with they can't figure that out.
Gogs seems to be an option but it seems to be missing a very important feature of code review.
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).
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?
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 :)
Documentation seems to be ahead of current GitLab release. This failing task will be included in a following patch release, very soon.