We are currently in the process of finding ways to implement many formats more quickly. It's certainly on our radars, although I can't promise it will make it into the next release.
I'm thinking we're going to do this as the next change to the issue boards, before anything else [0]. I'm aware everyone wants this and it makes total sense.
Yeah, the feature set might be good (better than GitHub, I don't know), but every time I try GitLab or use Bitbucket, they're just so sluggish compared to GitHub it puts me off. Edit: I just tried GitLab again, and it looks like they've made good progress in this area -- still seems significantly slower than GitHub, but it's no longer dog slow to just browse source code.
We run GitLab via the omnibus package in our data centre on a modest VM and it's no slouch (2 CPU, 8GB RAM with ~15-20 users and about 10 active projects). The hosted option isn't the fastest, though.
Plenty of work is being done in terms of performance improvements, and almost every release features a large set of improvements. A list of all performance related merge requests that have been merged can be found at https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope....
The slow loading of the community pictures in the background of the gitlab landing page (about.gitlab.com) gives the impression that it's very slow even if the relevant content on the page loads much faster. At this point Gitlab has a reputation for being slow so fighting this has to also be done at the perception level; not only ttfb level.
Yeah, a few folks mentioned the hosted version is fine. However, I am not interested in hosting my own instance. That's said, I don't mind paying a small monthly fee if it means getting a faster cloud service on less crowded servers.
Another release we're very proud of. Much of the work this release we spent on improving our idea to production flow and demos [0], things that'll trickly in over the coming releases.
We're also focusing on some longer-term improvements in UX [1], and are happy to ship some nice iterations with issue boards and merge conflict resolution.
Lastly, we're slowly building up review apps, which allow you to see/play with/test your changes running in a live environment. A very powerful concept and one we hope we can bring to everyone.
review apps are super exciting! That's the exact kind of interface I've been hoping for. I really hope it's available like the commit status api is (we use that for posting our custom CI builds). We currently have our own review app system at our company (and no hopes of switching to gitlab ci in the future - unfortunately :( ), but it'd be amazing if we could tie into it the same way we do for CI -- just "here's the link, it built succesfully!" would be a huge improvement to our workflow. Currently we treat it as a separate build (posting to status, with the url being the review app). Then because the URL didn't seem very visible on gitlab, we post it in the merge request too. Not nearly as nice as this would be!
Review apps are 'just another GitLab CI job'. But you can now set an external url in every environment. Every review app will have an environment create for it and you can add the URL there. I'm not sure the external url is in the API yet, but if not it is a question of time.
Thank you so much! That's amazing to hear. I think that will work for us. And as always, thank you for being one of the most outward communicating CEOs!
Speaking of UX, would you consider improving the look of Markdown rendered text (usually README.md) in the repo browser? On GitHub they look great and it's a pleasure reading Markdown formatted text there. In GitLab it's however not very appealing. Headers, spacing between them and paragraphs doesn't look very good IMO.
Coming from a previous job where we used GitHub and TeamCity, something I miss with GitLab is the ability to create a pipeline that's not connected to a specific Git branch. I'd like to be able to create a pipeline that can be triggered manually, without first having to create a dummy branch to put a .gitlab-ci.yml there. Is that something that's on your roadmap?
I find the whole design of GitLab not appealing to my eye. The recent redesign was a step in the right direction but I am still missing visible separators (e.g. boxes, lines, colored background) between/around areas for example on the page of an issue.
I have to agree. When I first started using Gitlab, it was quite jarring.
I'm much more happy with Gitlab's UI now that I've spent a lot of time with it. At least I don't fight with the interface after becoming familiar with it (it's no iTunes).
Thanks for the feedback, and I'm sorry to hear about the issues. We will continue to iterate and improve upon the design of GitLab based on feedback, and I hope we will address your concerns.
Regarding Markdown renderering, from my perspective the most important improvement is reducing the line width to a better readable character length. This is already addressed [0] and on the list for the 8.14 release. I agree that the spacing can be improved. In general, my impression is that there is a good awareness for required UI improvements [1] in the GitLab team. So I’m looking forward to the upcoming releases.
I do not understand the appeal of squashed merges. The only pro i know of is the ease of reverting a merge. On the cons side: you obfuscate an entire branch into a single commit, effectively making git-bisect useless. Furthermore, if multiple people collaborate on a branch, all code blames to one person, quite literally rewriting the code history.
Squash merge would be most useful in cases where someone turns in a PR and then there's back and forth which result in them making additional commit such like "Fix typo" and "Change struct name". That's not useful history and it's sometimes easier just to squash merge rather than give the contributor a lesson on reabse every single time. Naturally you shouldn't squash if the history needs to be cleaned up manually but it's rare to have multiple authors on one PR.
It's going to be highly pipeline, workflow, and team interaction dependent. In my place of work you generally only have one person working on a branch to add small, modular features. For releases we cut master into release branches. We fairly frequently need to downstream a commit from master into the staging branch and more rarely the production branch. The squash allows for a quick and easy cherry-pick of the feature to apply downstream.
If the code change is not widespread, I would always encourage a squash. Commits to two different parts of the codebase that do not directly rely on each other on the other hand should remain separate.
actually they always merge via -no-ff.
and time tracking in issue's is also a ee only thing.
actually the last releases were pretty much focused on ee-only stuff, it's sad that it will be more closed caused by the money.
Since the GitLab folks hang around here... any chance you'll let us force a redirect to HTTPS for GitLab pages with custom domains? Loving GitLab so far though!
Having a lot of issues with our merge requests never merging and just spinning forever.[1] Would like Gitlab to put a little more focus on those kinds of dealbreaker issues. Would hate to give up such a great product because of things like that.
We deployed GitLab just a few weeks ago in our setup and we can already see its impact on our development process.
Sometimes GitLab becomes extremely slow. A few days ago it became so slow that we had to check what was wrong and we found that a process named "bundle" taking up too mach memory and CPU. As we do not have a lot of experience with GitLab we could not figure out the reason behind "bundle" process eating up memory and CPU and therefore we tried restarting GitLab and everything was fine again.
not impressed with Merge Conflict Editor, would be a lot better as visual diff with two versions next to each other (ala meld), not to mention arrow buttons to quickly pick version without touching text.
48 comments
[ 3.6 ms ] story [ 116 ms ] threadRaw: https://raw.githubusercontent.com/stitchfix/Algorithms-Noteb...
[0] https://gitlab.com/gitlab-org/gitlab-ce/issues/2508
Finally. I missed this so much. Loving the work GitLab is putting in to their product.
Now, if only I could rearrange backlog items.
[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/21264
If you'd like to help out you can read up on the contributing guidelines at https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU....
Alternatively, any issues with data on what is slow and how these patterns can be reproduced is also greatly appreciated!
[0]: https://gitlab.com/gitlab-com/infrastructure/issues/59
We're also focusing on some longer-term improvements in UX [1], and are happy to ship some nice iterations with issue boards and merge conflict resolution.
Lastly, we're slowly building up review apps, which allow you to see/play with/test your changes running in a live environment. A very powerful concept and one we hope we can bring to everyone.
As always, we're here for any questions.
[0]: https://about.gitlab.com/2016/08/05/continuous-integration-d...
[1]: https://about.gitlab.com/2016/10/19/gitlab-ux-update/
Coming from a previous job where we used GitHub and TeamCity, something I miss with GitLab is the ability to create a pipeline that's not connected to a specific Git branch. I'd like to be able to create a pipeline that can be triggered manually, without first having to create a dummy branch to put a .gitlab-ci.yml there. Is that something that's on your roadmap?
I'm much more happy with Gitlab's UI now that I've spent a lot of time with it. At least I don't fight with the interface after becoming familiar with it (it's no iTunes).
[0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/13680
[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/22192
If the code change is not widespread, I would always encourage a squash. Commits to two different parts of the codebase that do not directly rely on each other on the other hand should remain separate.
[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/2995
Sometimes GitLab becomes extremely slow. A few days ago it became so slow that we had to check what was wrong and we found that a process named "bundle" taking up too mach memory and CPU. As we do not have a lot of experience with GitLab we could not figure out the reason behind "bundle" process eating up memory and CPU and therefore we tried restarting GitLab and everything was fine again.