GitLab 8.0 released with new looks and integrated CI
about.gitlab.com
about.gitlab.com
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.
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.
@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:
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. :)
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.
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.
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?
This is where I shamelessly tell you that we're hiring for almost any position.
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.
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?
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.
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.
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.
Concrete suggestions more than welcome on feedback.gitlab.com or here.
- 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"
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.
edit: following advice in this issue worked for me - https://gitlab.com/gitlab-org/omnibus-gitlab/issues/804
There appears to be an open issue at https://gitlab.com/gitlab-org/gitlab-ce/issues/2160
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)."
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
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.
> 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:
Display detailed information. Commit number, message, repo. (What you are showing today)
(Username) made X(number) of commits to private repo/s today.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.
The correct and active account is @gitlabstatus
Note that you can still integrate with your current CI.
This first step was necessary to clean up clutter in the UI.
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.
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".
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).