We are in the middle of migrating from Bitbucket to our self hosted CE version and apart from a few permissions issues on SSH keys we have had no issues with the whole process and updating our deployment system was just a case of changing git urls.
I've moved from BitBucket to GitLab and on the whole it works well. I still use GitHub for open source projects though.
One problem is that a lot of things automatically work with BitBucket and GitHub but GitLab need manual setup. For example, TeamCity has out-of-the-box support for both BitBucket and GitHub but you have to set up GitLab as a raw git repository (and create a user for it etc.).
edit: I should add that I've also used GitHub professionally with private repositories. However, I quite like having separate credentials for open source vs. more sensitive work.
Is there anything we can do from our side? We're very interested in making it easier to integrate with GitLab, but also happy to invest some time into making existing integrations easier to set up.
Our hope is that with time, it'll become obvious that when developing an application, you integrate with GitLab as well as with BB and GH.
Since I have your attention, something else that I think should be on your radar is creating/defining supported injection points in GitLab's UI. If you haven't done so, you should look at what Microsoft has done with Visual Studio Team Services.
By providing supported injection points in GitLab's UI, GitLab will be able to signal to others, that they are a solution you can safely build on top of.
Right now, to integrate deeply, you'd have to go through the heavy-handed process of creating a service [0]. That then does allow you to do almost anything, but the barrier to entry for that is high.
I created an issue for your proposal and hope you can provide some more feedback on how this would work, ideally [1].
I'm constantly impressed by how involved GitLab engineers are not just on HN but other communities when brought up. Not sure if you guys have people constantly looking for mention of "GitLab" but even if you are, the responsiveness and agreeableness to look into issues and invite people to be a part of the solution they seek out are phenomenal habits and I applaud you guys for it. It's one of the many reasons I converted a while back from Github and probably wont be looking back anytime soon.
This is great to hear and I personally think this the next battle front for gaining/retaining Git users in Enterprise. I'm currently working on integrating with Bitbucket and Microsoft, and I'll comment on the issue in a few weeks and provide some feedback.
Maybe create a plugin for Visual Studio, like GitHub does. Also try to work with JetBrains to make their GitHub plugin work with GitLab?
The GitHub plugin is available during installation, both with Visual Studio and JetBrains products, which makes it much more convenient to use. Things like creating a gist from code in IntelliJ or PyCharm also work out of the box with github.
We're exploring the VisualStudio option but as Job said we currently don't have the knowledge to make that happen. I've logged an issue for this request https://gitlab.com/gitlab-org/gitlab-ce/issues/20686 you can back it and follow it there.
As for JetBrains, we discussed this option with them - it would help if you create an issue for that on their platform as a user request to surface it. The more demand their users will have for this request the more likely it is to happen.
Why doesn't LFS support SSH authentication? It has been requested numerous times and has missed numerous milestones. I'm still not convinced it will hit 8.11. We desperately need LFS support, but we use one time tokens, so LFS Authentication over HTTPS just won't work for us. We are an EE customer and this future is way more useful than a UI redesign! https://gitlab.com/gitlab-org/gitlab-ce/issues/3589
We're planning to do this as soon as possible. I agree that it has taken a long time. We simply did not have the capacity with the people that are able to work on this, to build it earlier.
We now have strengthened the team that works on these issues. I'm seeing whether it's possible to ship this with 8.12 (due Sept 22nd).
Git-LFS is a github project, you'd be better off asking them. But yeah I share your exp. without SSH and with all its numerous bugs LFS is one of the worst pieces of software i've come across. We switched to using rsync for binaries/ large files etc.
Just to give you guys some credit: I've had the pleasure of working with RhodeCode on my previous job 2.5 years ago and it was an awesome experience. HG & Git support, full-text search, repo-specific access control, a nice gui, easy setup, etc. Unfortunately, most devs and sysadmins I talk to don't even know about your product, which is a real pity, as they all use the same inferior products and don't know what they are missing out on. Now i'm stuck with gitlab and bitbucket-server, which everyone thinks are great, but every time I log into them I silently cry out for rhodecode. Hope you guys are doing well.
@dvdgsng We're better than ever, thanks! I don't know if you heard, RhodeCode CE is now free and open source. Feel free to join our Slack: https://rhodecode.com/join
We'll be rolling out a major release next week, might be the right time to spread a word to colleagues ;)
We hope to ship Issue boards[1] this months, which will be a mayor improvement! But maybe you could be more specific to what you're missing? We'd love to hear your feedback!
Issue boards is great, but this is far from what we would need, tbh. We need a bugtracker, not a scrum board.
Mostly, we need a way to defined custom fields to be able to triage, query and reassign automatically. Like for example components or platform. And labels are clearly not enough for that.
I feel as though some of the recent UI changes were cosmetic and degraded the experience. I was especially unhappy about the sidebar being pushed into a hamburger menu (which can be pinned open, mind you).
I'd really like for UI updates in the future not to be jarring and seemingly pointless. I really liked the UI right before the overhaul, only minor tweaks seemed truly necessary. Many of the tweaks I would have suggested before have come through; such as putting profile information and notifications in the upper right hand corner. I'm glad about that.
Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.
I've asked some people that work on our UI to respond, but we're aware that we have some ways to go before it's really good and that the large changes that we're making can be painful at first.
> Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.
Could you elaborate on what kind of features we'd be required to add given your suggestion? What do we miss?
Thanks for your feedback - we are always working on improving the UX/UI and appreciate your input! I know that large changes can feel jarring at first but we hope that in the end, they help improve workflow and productivity.
The sidebar is a global navigation and not always necessary when interacting with page-specific content on the site. GitLab is very content heavy and by allowing the sidebar to be collapsed, it allows users to have more space on smaller screens to read/scan the information that they need. As you mentioned, the sidebar can be pinned so users can view the navigation all the time if they prefer, esp if they are using a larger screen.
If you have other examples of changes that you felt were pointless, I'd love to find out the reason for the change for you!
Was over a year since I last used GitLab, and I wonder if the resource usage and response times of a self-hosted instance has improved? Back then we were 3 developers having roughly 20 repos. The memory usage was over 2GB when idle and response times were at best between 2-3 seconds.
Testing your hosted version, loading this page[1] for example takes 4 seconds (3.6s TTFB). Don't get me wrong, the platform and its features are very broad and very good, but I personally can't stand having such long loading times. It's very frustrating because I really want to use GitLab and its features.
My feedback would be to set a main focus on reducing the TTFB for the Web UI, but also the Git server, because it takes a couple of seconds for it to respond to pushes.
I get 5.5s now when I re-run it (probably due to caching). We've been working incredibly hard to make it faster, we have to use it everyday, so we know exactly how annoying the lack of speed can be.
We've focused on speeding up some more common pages (Issues, MRs, etc.), but still a ways to go for the rest of the application!
Ceph should make a big difference once we get GitLab.com running on it in a few months, the reason the commits page specifically is so slow is because our current infrastructure is bottlenecked by filesystem-heavy interactions (e.g. getting all the recent git commits for a repository).
If you run your own instance of GitLab now, it will be fast. Since last year March we've grown from 9 to now 100 people, many of which dedicated to performance.
GitLab.com is slow, occasionally painfully so. We're very aware of that and are working to improve that. You're welcome to watch or contribute here [0].
I just finished an evaluation of Gitlab for our company and I'm blown away by all the awesome little touches that are geared toward productivity (merge requests that can be merged to a second branch with two clicks? yes please!).
That said, I'm holding off for now because I'd love for it to replace both Github and our current ticketing system, and rather than doing two migrations, I'd rather wait a few months until you guys have fleshed that out and do it all at once. The issue boards on your roadmap look absolutely fantastic, but the true killer feature I'm waiting on is time tracking, which I'm hoping makes it in later this year. Get that in and I think you'll see people flock to Gitlab.
Why do you offer hosted EE gitlab free? I mean I love it but that seems to run counter to keeping gitlab around. In fact there seems to be no way at all to pay for gitlab, without having to host a local install.
We do recommend you allocate resources generously, with 2Gb minimum.
That said, there are ways to tweak it. I believe you can reduce the default amount of Unicorn workers to one, as a start. Further than that I'm out of my league; I'll ask one of our awesome service engineers to respond here.
Working for a 15-year old small software company, I converted a whole bunch of ancient CVS stuff (yeah, yeah, don't laugh unless you also have 15 years of profitability) to GitLab CE. After a couple of false starts it went flawlessly and now works flawlessly.
(I used the tigris.org migration tools).
The GitLab team is doing a great job. Thanks you guys.
The false starts in our conversion were mostly struggles with how to restructure our old CVS repos so they made sense in the world of git. A few of them had to do with capturing some oddball CVS specific revision and branching history.
None of the false starts were due to flaws or confusion in GitLab specifically.
I should, and if you pester me I will, sanitize our internal how-to documents and scripts and contribute them to the Gitlab community so the next guy can benefit from our experience.
It would be great to receive some contributions to our documentation. It has proven a big challenge to make sure it covers everything and stays up to date. We'd really appreciate it.
One of the most successful companies I worked at had no version control or unit tests whatsoever. The code was all maintained by one person (the company relied heavily on custom software internally but it wasn't their product), who was able to keep the codebase small enough to basically hold in his head the whole time despite generating millions of dollars of value.
That's certainly not how I would write code today, but it is amazing to see how much top-notch programmers vary.
So far every early stage startup I've seen was using GitLab unless they only have open source / public projects and can use GitHub for free or need GitHub because of the community (it's still easier to get traction on GH as an open source project because so many developers already have a GH account).
GitLab has seen steady growth for years and has recently been gaining an increasing level of attention (in part because of the pricing changes and dodgy politics at GitHub). It's here to stay.
I hope GitLab.com will become more performant and stable. I would love to see GitHub for open source be replaced with a company actually built around open source rather than proprietary tech and catchy marketing.
I login to my server once a week and run a yum update. Backups are scheduled, so I don't have to concern myself with that.
No troubleshooting. But we're a small (<10 developers across 4 repos with access granted to ~ 30 people to GitLab for ticketing) team. Even my non-technical people are able to use GitLab for ticketing without bugging me, so that's fantastic.
Spent 30m installing it and configuring SSL. Nowadays I spend a couple of minutes monthly doing "aptitude update && aptitude install gitlab-ce" (after 5-15m reading about the new release, to see if it's worth it / problem free). We never had an issue with the auto-upgrade.
It comes with support for automatic offsite backups (we use S3), so besides occasionally restoring to make sure they're working, that takes no time at all.
I'm using paid GitLab hosting via the GitLab-owned GitHost.io, so zero: everytime an update comes out I get two e-mails and that's it.
The pricing is extremely competitive. We are a small shop so the smallest package ($35, recommended for up to 30 active users) is good enough. We started with a self-hosted GitLab via docker and switched to GitHost as soon as it was bought by GitLab.
If you don't want to maintain GitLab, either CE or EE, but would like to use it, you might want to take a look at GitHost.io
The instance I maintain takes me about 15 minutes a month. Security updates are done automatically so all I've got left to do it 'apt-get install gitlab-ce' once or twice a month and thats it!
Like 5 min install it, ~30 min configure it, then about every two weeks spend 5~10 min check any new release and release notes, then just "docker-compose pull && docker-compose up -d" to upgrade.
I recently moved my personal project from GitHub to GitLab and the whole process took me less than a minute, with a simple git remote set-url on the client side.
The future is amazing.
Sure!
The only reason I wasn't using GitLab before is that I had a writer working remotely on my game and I didn't know how to explain to her how to use it. So I had moved everything to GitHub and told her to use their desktop app, which makes the clone/commit/push/pull flow amazingly simple.
Not wanting to diminish what GitLab is doing, but what you mention is an inherent characteristic of git itself that applies the same way to GitHub, Bitbucket and a self hosted git bare repository. Any git host should expose a git interface for it to work as a git repository.
Yes, but they simplified it a lot. I just connected to github, chose the repository and clicked import. Maybe all of those services have it that way, but I'm just glad that GitLab had it.
That is a different case than configuring a different remote on config and pushing to another host which is what I interpreted reading your comment, my bad.
Out of curiosity, does the import process include all issues, PR and comments?
I have this problem too. It's not hard to set up, there are just so many tiny pieces that need to be run by hand that it's going to take a human well over an hour to read through the docs and get it right.
Someone made a Saltstack state[1] that I've used and had some success with - installing and configuring Salt from zero and using this config is still faster than installing Phabricator by hand.
Gitlab is unfortunately a pig, in the large and bloated sense of the term. Which is really sad! I love the app, it looks better than Phabricator and does so much more, but then I can throw Phabricator on the same droplet I use for plenty of other stuff with resources to spare for $5/month, where Gitlab would require a dedicated $10 instance just due to memory usage alone.
If only phab didn't insist on squashing a patchset into a phabricator-commit, losing the carefully created history of a branch. Cumulative mega-patches are of little use when bisecting or trying to understand how a change works by being able to follow the steps to reach the final diff. A good commit history with separate commit messages explaining the diffs goes much further in allowing someone else to understand a change than any code comment could. This is also why merge commits are useful, because they allow you to group the commits for a feature branch and not miss any of the commits involved.
Phabricator could easily include their metadata in a merge commit, instead of collapsing the branch into one mega-commit. I know some people love a flat history without merge commits, but those lose a lot of info available with a graph/tree visible when there are no forward merges.
Thanks for the link. As arcanist is the php-based client to speak to Phab, does this mean it's a user setting only and is fully respected by Phab, meaning it's something set on first publishing of a diff and kept in that setting? Is this also possible when submitting a diff via the web interface?
What's funny is that mutability didn't exist for Mercurial support because when it was written Mercurial had no official mutability feature.
And I can only suppose mutability being default for git support is because of Facebook's dev style. It's wrong to assume that those who want merge commits for the final merge onto master do not rebase locally before sending a pull request. Rebase is a standard tool for working on your branch (aka patch set aka patch queue) and it's normal to rewrite it upon each revision of the branch sent for review. Does phab support multiple revisions of a branch in one diff or does it require separate diff tickets? This is something that Gerrit got right, allowing one to see the diff between revisions of a branch (patchset).
Have not used them, but I really appreciate how their copy is written to appeal to devs. Ex:
Customizable Task Management
Plan features, track bugs, and award tokens. Maniphest lets you customize input forms, use custom fields, and has a rich API.
Keeps track of lots of bugs.
You can assign them to people.
Maybe you could fix them, eventually. (optional)
Build unique task forms for every department.
For example, look at this feature in Phabricator itself: T6526
-
Business Rules
As your company scales, keep track of activity with Herald, which notifies you when things you care about happen (like a specific file being changed).
Write business rules.
Everyone loves business rules.
Keep an eye on suspicious new hires.
Warns you about plotting and scheming.
Build triggers on tasks, commits, revisions, and more.
What is the benefit of moving to Gitlab from Bitbucket (or Github) for private repos?
Same feature set, Gitlab cost more per user and on top of all you have to run your own server? Am I missing something here?
I'll leave the marketing talk to less biased people here, but do note that:
- you can use GitLab.com for free: unlimited public and private repositories, unlimited collaborators, free hosting of your Docker images, free hosting of your static site with any static site generator and free CI / CD
- GitLab CE is fully open source (MIT Expat). You can easily install it anywhere you want.
It seems like that is the main selling point. However, I think that most of us don't want the extra weight of managing yet another tool. Thus why many of us use GitHub to begin with and not something else...
You can use GitLab.com with no charge. It's free in the same sense as GitHub is free, except it also runs on open source software (well, GitLab EE, which is a superset of CE and has a proprietary license but is still developed and supported in the open unlike GitHub).
AFAICT the "cost" is that you're effectively load-testing GitLab EE and help guiding the development of a commercial product. Plus you're giving GitLab free marketing. But to the extent that anything in life can be considered "free" (as in "gratis"), GitLab.com can be used for free.
We're thinking about charging for specific GitLab Runners in the future (think Mac Runners) or additional storage (we have a soft cap of 10GB per repo).
My big concern when I see a company that gives away too much for free is that they are probably unprofitable and will at some point:
a) Start charging for things that I'm used to having for free
and/or
b) Go bankrupt/get bought out by a company and disappear
Do you really sell enough enterprise licenses to give all the rest of this stuff away? From a look at your site, that's the only source of profit for your company that I can find.
You mentioned Mac runners, and if this includes iOS you'll make a killing. Figure out how to interact with a fast Android emulator and you'll be able to pull in a decent chunk of agencies that don't want to buy in house build machines.
How about costs compared to Bitbucket? I appreciate what you guys are doing but I think Github is cashing in on their brand and for a while they had the best UX (they still might! but I no longer care anymore as all the competitors are "good enough" for me) which lets them set a high premium people will pay. However, I think it's unfair to leave out Bitbucket, they have come a long way.
The first example of 8 developers and 20 repos is $10/month
or 100 developers and 300 repos examples is $100/month
What is the cost and/or time involved in maintaining DigitalOcean (or whatever VPS)? Security updates, upgrades, redundancy/availability, backups, or when something goes wrong the time involved in debugging/fixing (github/bitbucket have had their problems, is gitlab 100% available w/o hiccups)?
Very little time, in my experience. unattended-upgrades takes care of most security updates, a gitlab update is just "aptitude update && aptitude install gitlab-ce", and it automatically handles offsite backups.
If availability, security, backups etc. are highly critical for you and you don't want to host yourself, you could also have a look at our GitLab hosting service called GitHost (https://githost.io). It gives you your own private and secure GitLab instance on DigitalOcean which is completely maintained by us.
I've run Gitlab for about a year now and I think it's great.
However it is sluggish on a 1GB box and I think you need at least 2GB. Since Linode doubled the RAM on their $10 boxes then you can get it for the same price.
My gitlab-ce instance runs on a vm on an internal hypervisor machine. I just upped the RAM provisioning from 2gb to 4gb, and now it's plenty fast.
One of the benefits of working for a software company that started in the pre-cloud era is a surplus of server boxes, now retrieved from colo racks. :-)
I really liked Gitlab when last I tried it, but in the end I went with https://gogs.io/ instead. For a small-ish team this felt like the most straight forward self-hosted solution. Still missing LFS though, which sucks, but it's being worked on.
The native subversion and mercurial support for the same repos is incredibly attractive. Any idea how it converts them to a shared format in real-time?
I wish GitLab could be a bit lighter weight as well. I'd love to spin up the cheapest VM instance I can find on a cloud provider, pull a Docker container, and have a working GitLab instance up and running, but they "strongly advise against" running GitLab at the amount of memory those cheap VMs usually come with (usually around 512MB) [1].
gogs is pretty slow as soon as your repository gets bigger. At least when I last tested and contributed to it a few months ago. IIRC gogs parses the whole "last commit to this file or directory" before sending the response which is pretty slow.
I don't know how to feel about that, on the one hand it's "not using the soap you're selling" and makes you seem disingenuous about the quality of your product.
However, it is the "home of developers" right now, and they probably would prefer a low barrier to entry for people to get involved.
Many large (or aspiring) open-source projects seek to create a community of users around it, and having a lower barrier of entry to create such a community only helps the project. As you've said, GitHub provides such a low barrier.
I totally understand why people host open source projects on GitHub.com, most open source developers have accounts there so it lowers the barrier to contributing.
BTW If you host it on GitLab.com people can login with their GitHub account.
We did a comprehensive internal review of both gogs and gitlab. Gogs was a long way ahead of gitlab in terms of stability/speed and had pretty much all of the features developers tend to need.
I was trying to look into Gitlab Runner the other day. How decoupled is it from Gitlab itself? Would I be able to somewhat easily write a completely different UI, with a different framework/language (say, Django), hook it all up to Github/Gogs and use Gitlab runner for the jobs themselves?
Because if that's what it is, that is pretty kickass.
The Runner interfaces with GitLab through a pretty simple API, so you could do that.
One caveat is that we might introduce a new API by releasing a new version of GitLab and GitLab Runner at the same time, then you would need to upgrade you project to stay compatible.
BTW To ensure nobody is confused, you can use GitLab Runner to test all kinds of projects on all kinds of hardware. We're discussing developing an alternative to GitLab but reusing GitLab Runner.
Im using Jenkins right now to basically handle docker deployments. Without taking the time to actually read up on it in depth, does GitLab CI handle ways for me to essentially just pull prebuilt images and run them on a targeted server with desired settings?
I'm already preparing to move to GitLab CI for images that I build myself (since Im already storing the Dockerfiles on gitlab)
That seems to be referring to using docker images as part of the build process.
Im referring to using docker images as the deliverable. I mostly want to just have a gui to do "docker pull x" "docker stop xcon && docker rm xcon" "docker run --name xcon -v /volumes/x/config:/var/www/config -p 8080:80 x" for me. There would technically be nothing to be stored in the gitlab repo here, except the config.
Replace the "docker pull x" step with docker build in the event that I'm using a dockerfile to build a custom image, which could trigger as a result of updating the dockerfile... but usually the dockerfile doesnt change, it just needs to be re-run to pull in upstream changes.
Thanks for clarifying. I'm pretty sure you can do everything you want here. You could install a runner on your production box and run those commands within a deploy job.
In case you would like to shave a couple of seconds off per build, you might want to build a docker image with both luarocks and love already installed.
This would also be a great reason to test the awesome GitLab Docker Registry[1], which is also included in CE!
I highly recommend using Löve; the simplicity is very compelling.
I wrote a bit about testing on my blog, but it's more about the architecture of how the user-input system meshes with the internal reprogrammability. There's a bit about fuzz testing though: https://technomancy.us/180
Maybe I'll follow it up with a more detailed post specifically about automated testing in Löve since it seems to be not well-understood.
Well, unfortunately I don't have many contributors yet, so I can't speak much to the collaboration features. The only thing I can think of is that it would be nice if it were easier to get CI failures announced in Freenode channels. I haven't looked into it in a while, but last I checked it was a bit tricky to hook up push events into IRC.
All the minor complaints I had a while back have been addressed (not showing the readme as the splash page, and not being able to reply to issue emails) so I've been quite happy with it.
I also appreciate how force-pushes to master are disabled by default. The fact that my browser's Emacs key bindings don't get stolen by the issue textarea to do stupid markdown stuff is very much appreciated. (glares fiercely at github)
I was pretty impressed how easy it was for me (a server newb) to setup my own GitLab CI on a AWS server. For my projects now it takes around 15 seconds from when I push to GitLab for it to be deployed.
Earlier this week I had a family member get spooked by a web site with a fake blue screen tech support scam, the one where they tell you your computer has dire issues and you must pay them $300 to fix it. The page was taken down as of yesterday, but what is Gitlab doing to address this type of abuse in general?
Not sure why the downvote, the article keeps bagging about saving cost, when Linode would have been a much better fit and cheaper.
This isn't another ads or trolls. It is similar to AWS topic and recommending GCP, or Microsft Azure, all three are classed as similar with different tradeoff. So is Linode and DO. I do not think there are any other VPS provider then are in their class mindset wise.
We moved from BitBucket on premise to GitLab CE on premise.
Actually most things now just works.
Updating is a breeze.
Instead of downloading a installer and copying / fixing server.xml we can just do a apt update && apt upgrade -y.
Some things are a little bit akward but BitBucket didn't had this, too:
- FF only merges is only EE (too bad that would be a really major selling point even for CE, squash button would be unnecessary)
- Artifacts API is limited to everything or nothing
- CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)
- No Custom CSS (yeah our logo isn't 72px x 72px...)
But then again BitBucket didn't had these things anyway so except the bug it's nothing that would've hold us back.
Everytime you wanted a Feature for BitBucket, the guys said that there is/was an extension. How dare that costed a shitload of money which would even superseeded GitLab EE.
Thank you for the awesome detailed feedback. Responded point by point below:
> FF only merges is only EE (too bad that would be a really major selling point even for CE, squash button would be unnecessary)
These are always hard choices to make for us. We wrote about these decisions here [0].
> CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines
We're still young, but confident that we'll get there! CI/CD is a major focus for us and we're working really hard to improve it with every release. Love to get specific feature requests for things that we miss in comparison with Jenkins.
Regarding the bug: I've pinged our PM on it.
> Artifacts API is limited to everything or nothing
Could you elaborate? I know we have numerous improvements planned, but I'm not sure about their prioritization.
> CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)
Hm, could you write a feature proposal for this [1]? It sounds like a great improvement.
> No Custom CSS (yeah our logo isn't 72px x 72px...)
We're extremely hesitant to do this, as we make many changes between releases. This would break custom css with every upgrade, in turn resulting in a worse experience.
I rather hear suggestions about specific parts in the interface that should be made customizable or suggestions about changes to the UI altogether.
Although I'm not a fan of custom css, there is an issue to discuss this and I welcome your input there [2].
Actually as already said even with the stuff mentioned here, it's really really a good project and we are happy.
to [0] we've gone the CE route first since we are too small and too fast running that a EE makes sense yet (too good that you can switch between the two without any major drawbacks [http://docs.gitlab.com/ee/downgrade_ee_to_ce/README.html] and [http://docs.gitlab.com/omnibus/update/README.html#from-commu...] thats one of the major selling points, ease of use is really big in gitlab). but sitll every feature mentioned here wasn't in bitbucket so it's not like we've missing something, we've gained something while switching so we are probably whining on a really high level ;)
Oh and thanks god for the easy backup stuff, which even works while running (which other products doesn't....)
> - CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines
Do you have more examples of workflows we are not supporting at all or well enough?
> - Artifacts API is limited to everything or nothing
Right you are, you might want to track this issue[1].
> - CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)
I don't fully comprehend what you mean, could you elaborate?
Not supported Workflows:
- JUnit XML or similar output reading to have a nice output what's broken / worked
- Checkstyle output / pylint / tools for other languages
- What I said about Artifacts
- Artifacts are hard to Track I already wrote into [1] which would also be a good way
- Actually external Triggers can't be conditional:
And I guess these are the things my company does / did with jenkins.
There is also another downside but we don't do that anymore:
You can't push from CI to master branches, some people do tag and create builds with their CI / CD (which we also did) but now we just push a Tag to the Repo and the CI will be: '- only: tags' and catch that up.
That's all stuff I can think of now which is probably not supported by most "simple" CI / CD Tools. I guess only the big one's have such a thing like TeamCity, Jenkins and Bamboo.
I'm working on a proper Docker setup for GitLab development which I think can be made production-ready pretty easily after the development version works.
It's hard separating the different moving parts (gitlab, gitlab-workhorse, gitlab-shell+ssh, postgres/mysql, redis) but I think I will have a merge request ready soon enough :D
Not right now. I'm following the install from source guide so it'll be as close as possible to production. I'll change some things the omnibus package does better, then apply the GDK stuff so people could use it for development.
I have some code. I guess I can submit a merge request + issue on gitlab-ce and gitlab-workhorse, but I need to read CONTRIBUTING and PROCESS first :P
I love how responsive our local (departmental) instance of GitLab CE is -- it's downright snappy compared to the corporate instance of JIRA. We love the issue tracking subsystem of GitLab and use it as our main ticketing system.
This is the sort of result it makes us very happy to achieve:
"I have got by on minimum understanding of Git for a couple of years now--this really brought up my confidence in using Git. After I learned the Git internals, the esoteric commands really started falling into place."
--Nicholas Santucci, Monitoring and Performance Engineer
We've done three physical events already. :-) I'll email you! Our next physical event will be teaching at Ohio Linux Fest (https://ohiolinux.org/olfi/)
Feature requests for Issues: priorities, and states other than open and closed. These are the biggest things keeping us from using GitLab issues rather than an external tool.
We need to be able to set priorities (ideally customizable, but at minimum high/med/low). We can kind of do that through labels, but it's messy because you can only search for one label at a time (no boolean combinations of labels).
Right now, when you assign an issue to a user, it's considered "in progress", and from there it can either be unassigned or closed. It would be nice to separate the state of the issue from the assigned user, since in our current workflow we assign many issues to a user, but that user might only be working on a few of them at a time. Using our current bug tracker, we can differentiate between "Open, unassigned", "Open, assigned", "Open, in progress", "Fixed", "Verified", "Closed", etc. I know having a completely customizable state diagram for issues is a big software task, but maybe there is some intermediary level of complexity that would allow better tracking of what is actually being worked on now vs. what is assigned to people.
Wow. The power of HN. We did our webinar today and had attendees from the Netherlands, Germany, Serbia and the US. It was exciting to have an international audience.
If your concern is cost, bitbucket always have free private repositories.
If your looking for privacy and protect your sacred code, install gitlab on one of your server or vps.
Thats what we do at SAIT
Fair point, but it's important not to fool ourselves in terms of data safety or at least specify what we mean when we say "it's private on your vps".
If your code is private and not meant to fall into external hands, then putting it on a VPS won't protect it. The only way is to put it on a machine that's only used from workstations that access it in a local-only fashion, inside containers/vms that have no way to contact the outside world. This means the build process may not access the internet and has to rely on a cache of external libs if needed and allowed. This also implies that network config won't allow access as forbidden via VLANs or similar measures.
If someone wants to steal your code, grabbing it from your vps won't be harder than doing the same on github/gitlab because the procedures to get access will be very similar.
I suspect by private code you mean code which shouldn't be publicly clone'able but isn't behind locked doors otherwise.
I would like to see that there is just one gitlab version, and that the enterprise features are simply available in the community edition too. I will not pay just for a feature like repo mirroring, but it's i think a feature many people will use and or utilise when moving, migrating to a gitlab setup.
But it is the one and only feature i am missing so not worth upgrading to EE for me.
As soon as an alternative (open source, self hosted, free) comes around that does have this built-in, i will be tempted to try it. (and of course on success i will move away from gitlab).
But for now, gitlab (CE) works best for me, self hosted.
We do our best to make CE and EE excellent, where the features that land in EE are mostly interesting for larger teams. For every feature that we don't bring to CE, this is always a hard decision.
I'd love to see an a la carte licensing option, where an organization could start with stock CE and license just the features they need. I realize that'd be a bear to implement, though.
I understand, and money has to be made too. It's a nasty trade off. Though as i wrote to the other reply, its the service that is worth the money not necessarily the feature(s).
IMHO, there is always a certain percentage of users that want to pay. The more users in total, the larger the amount of paying customers.
And the repo mirroring would be a great feature to let me move a lot of github project users to gitlab without losing any potential updates from an upstream source.
It would also allow for nice backup purposes, though you could do that now of course already with the hosted enterprise solution. But if the feature was in CE, many would be used, familiarised, to the feature, and perhaps see the added value of a backup node ($$) at gitlab.
If you think about what you're asking: youre asking for folks who build infrastructure you rely on to have no viable way of creating a self sustaining business model. Aka no virtuous circle. No development. This perspective is a classic tragedy of the commons situation and makes perfect sense for you to have as an individual. But it's sad.
There will always be users like me who know how to self host stuff and don't want 3rd parties having access to their repos. But there will always be plenty of people who like to outsource this, have it hosted by 3rd party etc etc. It's the service that is worth the money, not the features.
Features have a limited value, they are valuable until an alternative provides it for free (which is the common thing these days). And that will happen here too, just take times. Same as gitlab nibbled at github, something else will come around to take share from gitlab.
Simplifying the development to just one tree/version, saves a lot of maintenance, development discussions, allows feedbacks of all features by self hosting users as if they were enterprise hosted clients. This also has a value.
I wasn't refering to hosted vs not hosted. I was referring to the virtuous cycle of supporting people by giving them a viable business option who make software (whether FoSS and deployed on local infrastructure or hosted).
Do you believe Linus Torvalds deserves to have a salary? Are you happy he does? I sure am. Do you think that money grows on trees? It comes from people realizing that it's important to contribute to sustain the pieces they rely on. The majority are always free-loaders: I just think it's important to emphasize that if everyone were, the cycle of innovation would slow significantly.
FWIW, I recently transferred my side project from bitbucket to gitlab and I'm really happy with it. The issue tracker is significantly better, and the built in CI seems great but I haven't started using it yet since I already have codeship going.
I did the same last month and then transferred back to bitbucket.
The response time on gitlab.com was painfully slow. That extra 2-3 seconds waits for each commit was enough to drive me back. I still use github for professional projects and bitbucket for personal ones.
I had the same experience. The other thing I would add is that the social side of Gitlab is not as refined as GitHub's. There's no "timeline," for example.
On the other hand, gitlab's "network" view of commit branches is excellent and I've never been able to find anything remotely similar on Github. Essential to manage development in multiple concurrent branches.
It's similar, but gitlab's graph has a much more readable and sensible 2d layout. The way tig and gitk line up/layout the branches is often very confusing. Gitlab makes it much clearer where the branch lines go, while tig/gitk seem to left-align everything as much as possible, making the lines twist and turn and difficult to trace.
355 comments
[ 2.9 ms ] story [ 198 ms ] threadWell done Gitlab :)
One problem is that a lot of things automatically work with BitBucket and GitHub but GitLab need manual setup. For example, TeamCity has out-of-the-box support for both BitBucket and GitHub but you have to set up GitLab as a raw git repository (and create a user for it etc.).
edit: I should add that I've also used GitHub professionally with private repositories. However, I quite like having separate credentials for open source vs. more sensitive work.
Our hope is that with time, it'll become obvious that when developing an application, you integrate with GitLab as well as with BB and GH.
Addressing this issue will go a long way, in making it easier for others to create solutions that can easily integrate with GitLab.
https://gitlab.com/gitlab-org/gitlab-ce/issues/20567
For the upcoming release (8.11, August 22nd), we're adding deploy keys with push permissions [0]. This would allow you to basically do the same thing.
That said, that doesn't make it very clear that you can use these for this purpose, so I've added a note to re-evaluate these.
We're also expanding OAuth scopes, potentially making it easier / more attractive to integrate [1].
[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/1376
[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20492
By providing supported injection points in GitLab's UI, GitLab will be able to signal to others, that they are a solution you can safely build on top of.
Right now, to integrate deeply, you'd have to go through the heavy-handed process of creating a service [0]. That then does allow you to do almost anything, but the barrier to entry for that is high.
I created an issue for your proposal and hope you can provide some more feedback on how this would work, ideally [1].
[0]: http://docs.gitlab.com/ce/project_services/project_services.... Services
[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20667
> Not sure if you guys have people constantly looking for mention of "GitLab"
We do! Channels straight into chat.
There are some plugins listed here [0], but we hope to have official plugins in the future.
[0]: https://about.gitlab.com/applications
As for JetBrains, we discussed this option with them - it would help if you create an issue for that on their platform as a user request to surface it. The more demand their users will have for this request the more likely it is to happen.
We now have strengthened the team that works on these issues. I'm seeing whether it's possible to ship this with 8.12 (due Sept 22nd).
We'll be rolling out a major release next week, might be the right time to spread a word to colleagues ;)
However, you can already deploy from GitLab quite easily to Heroku, it just requires a single line in your CI config:
http://docs.gitlab.com/ce/ci/examples/test-and-deploy-ruby-a...
[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/17907
Mostly, we need a way to defined custom fields to be able to triage, query and reassign automatically. Like for example components or platform. And labels are clearly not enough for that.
I'd really like for UI updates in the future not to be jarring and seemingly pointless. I really liked the UI right before the overhaul, only minor tweaks seemed truly necessary. Many of the tweaks I would have suggested before have come through; such as putting profile information and notifications in the upper right hand corner. I'm glad about that.
Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.
> Other than that; I'd like to say that I have really liked using Pivotal Tracker for developing software. It has a rigid pipeline between requirements and results. Configurability ruins some productivity tools. It would be swell to have something like "Pivotal Tracker lite" associated with GitLab (in that GitLab CI is). It's not a difficult kind of software to do reasonably well, and it would make GitLab the ultimate software project productivity suite.
Could you elaborate on what kind of features we'd be required to add given your suggestion? What do we miss?
The sidebar is a global navigation and not always necessary when interacting with page-specific content on the site. GitLab is very content heavy and by allowing the sidebar to be collapsed, it allows users to have more space on smaller screens to read/scan the information that they need. As you mentioned, the sidebar can be pinned so users can view the navigation all the time if they prefer, esp if they are using a larger screen.
If you have other examples of changes that you felt were pointless, I'd love to find out the reason for the change for you!
I also urge you to voice your opinion by making an issue for changes that you think would help improve the user experience. https://gitlab.com/gitlab-org/gitlab-ce/issues/new
Testing your hosted version, loading this page[1] for example takes 4 seconds (3.6s TTFB). Don't get me wrong, the platform and its features are very broad and very good, but I personally can't stand having such long loading times. It's very frustrating because I really want to use GitLab and its features.
My feedback would be to set a main focus on reducing the TTFB for the Web UI, but also the Git server, because it takes a couple of seconds for it to respond to pushes.
[1] https://gitlab.com/gitlab-org/gitlab-ce/commits/master
https://tools.pingdom.com/#!/cOKg2F/https://gitlab.com/gitla...
GitLab.com is too slow. We're working on it here: https://gitlab.com/gitlab-com/infrastructure/issues/59
For example, take a look at the drop in response time in the middle of last month: http://stats.pingdom.com/81vpf8jyr1h9/1902794/2016/07
We've focused on speeding up some more common pages (Issues, MRs, etc.), but still a ways to go for the rest of the application!
Ceph should make a big difference once we get GitLab.com running on it in a few months, the reason the commits page specifically is so slow is because our current infrastructure is bottlenecked by filesystem-heavy interactions (e.g. getting all the recent git commits for a repository).
Ceph issues are here: https://gitlab.com/gitlab-com/infrastructure/issues?scope=al...
GitLab.com is slow, occasionally painfully so. We're very aware of that and are working to improve that. You're welcome to watch or contribute here [0].
[0]: https://gitlab.com/gitlab-com/infrastructure/issues/59
That said, I'm holding off for now because I'd love for it to replace both Github and our current ticketing system, and rather than doing two migrations, I'd rather wait a few months until you guys have fleshed that out and do it all at once. The issue boards on your roadmap look absolutely fantastic, but the true killer feature I'm waiting on is time tracking, which I'm hoping makes it in later this year. Get that in and I think you'll see people flock to Gitlab.
- https://gitlab.com/gitlab-org/gitlab-ce/issues/18687 - https://gitlab.com/gitlab-org/gitlab-ce/issues/20608
If you have ideas to improve the current vision, don't hesitate to join the conversation!
[1]: https://githost.io/
I've used omnibus installer and it was almost painless, only a couple of issues because of LXC limits.
My only concern is resource usage, it does take at least 2Gb memory, are there any options to tweak it?
That said, there are ways to tweak it. I believe you can reduce the default amount of Unicorn workers to one, as a start. Further than that I'm out of my league; I'll ask one of our awesome service engineers to respond here.
(I used the tigris.org migration tools).
The GitLab team is doing a great job. Thanks you guys.
Any way we can prevent those false starts for other people?
None of the false starts were due to flaws or confusion in GitLab specifically.
I should, and if you pester me I will, sanitize our internal how-to documents and scripts and contribute them to the Gitlab community so the next guy can benefit from our experience.
It would be great to receive some contributions to our documentation. It has proven a big challenge to make sure it covers everything and stays up to date. We'd really appreciate it.
That's certainly not how I would write code today, but it is amazing to see how much top-notch programmers vary.
GitLab has seen steady growth for years and has recently been gaining an increasing level of attention (in part because of the pricing changes and dodgy politics at GitHub). It's here to stay.
I hope GitLab.com will become more performant and stable. I would love to see GitHub for open source be replaced with a company actually built around open source rather than proprietary tech and catchy marketing.
No troubleshooting. But we're a small (<10 developers across 4 repos with access granted to ~ 30 people to GitLab for ticketing) team. Even my non-technical people are able to use GitLab for ticketing without bugging me, so that's fantastic.
Love it.
It comes with support for automatic offsite backups (we use S3), so besides occasionally restoring to make sure they're working, that takes no time at all.
The pricing is extremely competitive. We are a small shop so the smallest package ($35, recommended for up to 30 active users) is good enough. We started with a self-hosted GitLab via docker and switched to GitHost as soon as it was bought by GitLab.
The instance I maintain takes me about 15 minutes a month. Security updates are done automatically so all I've got left to do it 'apt-get install gitlab-ce' once or twice a month and thats it!
Checking backups once a week, 3 min.
Updates twice a month (using apt-get upgrade) 10 min counting integrity checks.
Nuisance factor: updating gitlab-ce drops a tiny little backup file in the backups folder.
`sudo touch /etc/gitlab/skip-auto-migrations`
Docs on it here: http://docs.gitlab.com/omnibus/update/README.html
Out of curiosity, does the import process include all issues, PR and comments?
(BTW labels are also imported)
https://github.com/new/import
Let me know how it works for you; happy to provide feedback to make it easier for your purposes!
Someone made a Saltstack state[1] that I've used and had some success with - installing and configuring Salt from zero and using this config is still faster than installing Phabricator by hand.
[1]: https://github.com/bougie/salt-phabricator-formula
Also a lot faster.
Guess I'm just not the target audience :(
Phabricator could easily include their metadata in a merge commit, instead of collapsing the branch into one mega-commit. I know some people love a flat history without merge commits, but those lose a lot of info available with a graph/tree visible when there are no forward merges.
https://secure.phabricator.com/book/phabricator/article/arca...
> Phabricator could easily include their metadata in a merge commit
And this is what happens :-)
What's funny is that mutability didn't exist for Mercurial support because when it was written Mercurial had no official mutability feature.
And I can only suppose mutability being default for git support is because of Facebook's dev style. It's wrong to assume that those who want merge commits for the final merge onto master do not rebase locally before sending a pull request. Rebase is a standard tool for working on your branch (aka patch set aka patch queue) and it's normal to rewrite it upon each revision of the branch sent for review. Does phab support multiple revisions of a branch in one diff or does it require separate diff tickets? This is something that Gerrit got right, allowing one to see the diff between revisions of a branch (patchset).
- you can use GitLab.com for free: unlimited public and private repositories, unlimited collaborators, free hosting of your Docker images, free hosting of your static site with any static site generator and free CI / CD
- GitLab CE is fully open source (MIT Expat). You can easily install it anywhere you want.
It seems like that is the main selling point. However, I think that most of us don't want the extra weight of managing yet another tool. Thus why many of us use GitHub to begin with and not something else...
AFAICT the "cost" is that you're effectively load-testing GitLab EE and help guiding the development of a commercial product. Plus you're giving GitLab free marketing. But to the extent that anything in life can be considered "free" (as in "gratis"), GitLab.com can be used for free.
We're thinking about charging for specific GitLab Runners in the future (think Mac Runners) or additional storage (we have a soft cap of 10GB per repo).
a) Start charging for things that I'm used to having for free
and/or
b) Go bankrupt/get bought out by a company and disappear
Do you really sell enough enterprise licenses to give all the rest of this stuff away? From a look at your site, that's the only source of profit for your company that I can find.
We're not planning to charge for what we give away for free now. Never.
We're thinking about charging for specific Runners for our CI (such as Mac runners) and possibly for extra storage.
The first example of 8 developers and 20 repos is $10/month
or 100 developers and 300 repos examples is $100/month
What is the cost and/or time involved in maintaining DigitalOcean (or whatever VPS)? Security updates, upgrades, redundancy/availability, backups, or when something goes wrong the time involved in debugging/fixing (github/bitbucket have had their problems, is gitlab 100% available w/o hiccups)?
GitHost for teams of up to 100 is $80/month.
However it is sluggish on a 1GB box and I think you need at least 2GB. Since Linode doubled the RAM on their $10 boxes then you can get it for the same price.
One of the benefits of working for a software company that started in the pre-cloud era is a surplus of server boxes, now retrieved from colo racks. :-)
[1] https://github.com/gitlabhq/gitlabhq/blob/master/doc/install...
However, it is the "home of developers" right now, and they probably would prefer a low barrier to entry for people to get involved.
I totally understand why people host open source projects on GitHub.com, most open source developers have accounts there so it lowers the barrier to contributing.
BTW If you host it on GitLab.com people can login with their GitHub account.
- code review
- deployment key
And the builtin SSH server will randomly hang once or twice every day.
We did a comprehensive internal review of both gogs and gitlab. Gogs was a long way ahead of gitlab in terms of stability/speed and had pretty much all of the features developers tend to need.
https://about.gitlab.com/gitlab-ci/
If you want to give it a spin, check out our recent blog post on starting from 0: https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/
Because if that's what it is, that is pretty kickass.
One caveat is that we might introduce a new API by releasing a new version of GitLab and GitLab Runner at the same time, then you would need to upgrade you project to stay compatible.
BTW To ensure nobody is confused, you can use GitLab Runner to test all kinds of projects on all kinds of hardware. We're discussing developing an alternative to GitLab but reusing GitLab Runner.
Docs: http://docs.gitlab.com/ce/ci/docker/using_docker_images.html...
Im referring to using docker images as the deliverable. I mostly want to just have a gui to do "docker pull x" "docker stop xcon && docker rm xcon" "docker run --name xcon -v /volumes/x/config:/var/www/config -p 8080:80 x" for me. There would technically be nothing to be stored in the gitlab repo here, except the config.
Replace the "docker pull x" step with docker build in the event that I'm using a dockerfile to build a custom image, which could trigger as a result of updating the dockerfile... but usually the dockerfile doesnt change, it just needs to be re-run to pull in upstream changes.
Two options for configuring the runner:
1: http://docs.gitlab.com/ce/ci/docker/using_docker_build.html#...
2: http://docs.gitlab.com/ce/ci/docker/using_docker_build.html#...
This would also be a great reason to test the awesome GitLab Docker Registry[1], which is also included in CE!
[1] http://docs.gitlab.com/ce/container_registry/README.html
I was thinking about making a game in Löve for a while now, but I have never done any automated testing with it.
Is there a good tutorial for that? Or do you feel like writing one? ;)
I wrote a bit about testing on my blog, but it's more about the architecture of how the user-input system meshes with the internal reprogrammability. There's a bit about fuzz testing though: https://technomancy.us/180
Maybe I'll follow it up with a more detailed post specifically about automated testing in Löve since it seems to be not well-understood.
Would love to hear your thoughts on developing a game using GitLab, anything we can improve in that regard?
[1]: https://gitlab.com/xonotic/xonotic
All the minor complaints I had a while back have been addressed (not showing the readme as the splash page, and not being able to reply to issue emails) so I've been quite happy with it.
I also appreciate how force-pushes to master are disabled by default. The fact that my browser's Emacs key bindings don't get stolen by the issue textarea to do stupid markdown stuff is very much appreciated. (glares fiercely at github)
This isn't another ads or trolls. It is similar to AWS topic and recommending GCP, or Microsft Azure, all three are classed as similar with different tradeoff. So is Linode and DO. I do not think there are any other VPS provider then are in their class mindset wise.
Some things are a little bit akward but BitBucket didn't had this, too:
- FF only merges is only EE (too bad that would be a really major selling point even for CE, squash button would be unnecessary)
- CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines https://gitlab.com/gitlab-org/gitlab-ce/issues/19455
- Artifacts API is limited to everything or nothing
- CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)
- No Custom CSS (yeah our logo isn't 72px x 72px...)
But then again BitBucket didn't had these things anyway so except the bug it's nothing that would've hold us back. Everytime you wanted a Feature for BitBucket, the guys said that there is/was an extension. How dare that costed a shitload of money which would even superseeded GitLab EE.
> FF only merges is only EE (too bad that would be a really major selling point even for CE, squash button would be unnecessary)
These are always hard choices to make for us. We wrote about these decisions here [0].
> CI is a little limited compared to a full blown Jenkins - We hit a CI bug which still shows up "Running" Pipelines
We're still young, but confident that we'll get there! CI/CD is a major focus for us and we're working really hard to improve it with every release. Love to get specific feature requests for things that we miss in comparison with Jenkins.
Regarding the bug: I've pinged our PM on it.
> Artifacts API is limited to everything or nothing
Could you elaborate? I know we have numerous improvements planned, but I'm not sure about their prioritization.
> CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)
Hm, could you write a feature proposal for this [1]? It sounds like a great improvement.
> No Custom CSS (yeah our logo isn't 72px x 72px...)
We're extremely hesitant to do this, as we make many changes between releases. This would break custom css with every upgrade, in turn resulting in a worse experience.
I rather hear suggestions about specific parts in the interface that should be made customizable or suggestions about changes to the UI altogether.
Although I'm not a fan of custom css, there is an issue to discuss this and I welcome your input there [2].
[0]: https://about.gitlab.com/2016/01/11/being-a-good-open-source...
[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/new
[2]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15635
Oh and thanks god for the easy backup stuff, which even works while running (which other products doesn't....)
Do you have more examples of workflows we are not supporting at all or well enough?
> - Artifacts API is limited to everything or nothing
Right you are, you might want to track this issue[1].
> - CI Stages can be defined as trigger only but you can't have multiple triggers that starting different things (considering a production trigger and a testing trigger while you don't want the 'manual' thing directly in GitLab, especially when integrating into other systems makes this a flaw)
I don't fully comprehend what you mean, could you elaborate?
[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/20603
https://gitlab.com/gitlab-org/gitlab-ce/issues/19826
So either that or have a way to name triggers which I opened here:
https://gitlab.com/gitlab-org/gitlab-ce/issues/20574
And I guess these are the things my company does / did with jenkins.
There is also another downside but we don't do that anymore: You can't push from CI to master branches, some people do tag and create builds with their CI / CD (which we also did) but now we just push a Tag to the Repo and the CI will be: '- only: tags' and catch that up.
That's all stuff I can think of now which is probably not supported by most "simple" CI / CD Tools. I guess only the big one's have such a thing like TeamCity, Jenkins and Bamboo.
It's hard separating the different moving parts (gitlab, gitlab-workhorse, gitlab-shell+ssh, postgres/mysql, redis) but I think I will have a merge request ready soon enough :D
Do you leverage GDK? [0]
[0]: https://gitlab.com/gitlab-org/gitlab-development-kit
I have some code. I guess I can submit a merge request + issue on gitlab-ce and gitlab-workhorse, but I need to read CONTRIBUTING and PROCESS first :P
We've done a few talks on Git basics to help increase adoption, and are doing a free webinar "Git Foundations: Basic Concepts and Definitions" next week: https://www.eventbrite.com/e/git-foundations-basic-concepts-...
This is the sort of result it makes us very happy to achieve:
"I have got by on minimum understanding of Git for a couple of years now--this really brought up my confidence in using Git. After I learned the Git internals, the esoteric commands really started falling into place." --Nicholas Santucci, Monitoring and Performance Engineer
If you plan on doing physical events, drop me an email (job at gitlab).
We need to be able to set priorities (ideally customizable, but at minimum high/med/low). We can kind of do that through labels, but it's messy because you can only search for one label at a time (no boolean combinations of labels).
Right now, when you assign an issue to a user, it's considered "in progress", and from there it can either be unassigned or closed. It would be nice to separate the state of the issue from the assigned user, since in our current workflow we assign many issues to a user, but that user might only be working on a few of them at a time. Using our current bug tracker, we can differentiate between "Open, unassigned", "Open, assigned", "Open, in progress", "Fixed", "Verified", "Closed", etc. I know having a completely customizable state diagram for issues is a big software task, but maybe there is some intermediary level of complexity that would allow better tracking of what is actually being worked on now vs. what is assigned to people.
If your code is private and not meant to fall into external hands, then putting it on a VPS won't protect it. The only way is to put it on a machine that's only used from workstations that access it in a local-only fashion, inside containers/vms that have no way to contact the outside world. This means the build process may not access the internet and has to rely on a cache of external libs if needed and allowed. This also implies that network config won't allow access as forbidden via VLANs or similar measures.
If someone wants to steal your code, grabbing it from your vps won't be harder than doing the same on github/gitlab because the procedures to get access will be very similar.
I suspect by private code you mean code which shouldn't be publicly clone'able but isn't behind locked doors otherwise.
But it is the one and only feature i am missing so not worth upgrading to EE for me.
As soon as an alternative (open source, self hosted, free) comes around that does have this built-in, i will be tempted to try it. (and of course on success i will move away from gitlab).
But for now, gitlab (CE) works best for me, self hosted.
We wrote about this here: https://about.gitlab.com/2016/01/11/being-a-good-open-source...
I understand, and money has to be made too. It's a nasty trade off. Though as i wrote to the other reply, its the service that is worth the money not necessarily the feature(s).
IMHO, there is always a certain percentage of users that want to pay. The more users in total, the larger the amount of paying customers.
And the repo mirroring would be a great feature to let me move a lot of github project users to gitlab without losing any potential updates from an upstream source.
It would also allow for nice backup purposes, though you could do that now of course already with the hosted enterprise solution. But if the feature was in CE, many would be used, familiarised, to the feature, and perhaps see the added value of a backup node ($$) at gitlab.
Features have a limited value, they are valuable until an alternative provides it for free (which is the common thing these days). And that will happen here too, just take times. Same as gitlab nibbled at github, something else will come around to take share from gitlab.
Simplifying the development to just one tree/version, saves a lot of maintenance, development discussions, allows feedbacks of all features by self hosting users as if they were enterprise hosted clients. This also has a value.
Do you believe Linus Torvalds deserves to have a salary? Are you happy he does? I sure am. Do you think that money grows on trees? It comes from people realizing that it's important to contribute to sustain the pieces they rely on. The majority are always free-loaders: I just think it's important to emphasize that if everyone were, the cycle of innovation would slow significantly.
The response time on gitlab.com was painfully slow. That extra 2-3 seconds waits for each commit was enough to drive me back. I still use github for professional projects and bitbucket for personal ones.
I hope you're willing to give GitLab another try when we've improved the performance of GitLab.com or by hosting it yourself.
Follow our work on GitLab.com performance here: https://gitlab.com/gitlab-com/infrastructure/issues/59
I pay for GitHub and enjoy it.
[1] comes with git, screenshot: http://static.lwn.net/images/ns/kernel/gitk.png
[2] http://jonas.nitro.dk/tig/
We have an Activity feed which you can set as your homepage if you'd like, though maybe it's missing features you'd like?
https://enterprise.github.com/home