GitLab 11 released
about.gitlab.com
about.gitlab.com
- batch review (seriously, will this ever be done?) (https://gitlab.com/gitlab-org/gitlab-ee/issues/1984)
- configurable tab width (https://gitlab.com/gitlab-org/gitlab-ce/issues/2479)
- consecutive git blame for current revision (https://gitlab.com/gitlab-org/gitlab-ce/issues/37135)
- rebase and merge in one single step (https://gitlab.com/gitlab-org/gitlab-ee/issues/895)
- unable to view diff for any file that is slightly large (https://gitlab.com/gitlab-org/gitlab-ce/issues/30061)
GitLab seems to be trying too hard to replace project management tools like JIRA and CI tools like Jenkins that it's neglecting its core feature set that is code repo management.
But instead of focusing on the core features, here's probably what they will launch instead:
- a slack like chat app
- a trello like app
- a yammer like app
- redesigning the left nav once again
- adding even more UI clutter in the merge request box because they still haven't jammed enough crap in there
Click this image in the top right-hand side: https://i.imgur.com/vWOxECQ.png
The ToDos is a sort of inbox of actionables. We don't use approvers because we use assignees for MRs but here you'll get anything that requires (or may require) some action on your part, like mentions, assignments, CI job failures you're responsible of... ToDos get automatically "done" when you act, such as replying to a mention. Alternatively you can manually mark some issues as "done" or "to do". I like this workflow personally use them to great effect by practicing a form of Inbox Zero, and combined with the personal issues and MR lists they give me a good picture of what I have to do.
Well, that's not flawless. I never use the TODOs view, because it's full of items like this:
https://screenshots.firefox.com/wxy2llOZM5g0HWre/gitlab.com
In other words, there's a number of issues assigned to me listed there, even though they're closed. There's also a few mentions that I don't otherwise interact with (I've seen them in my email and that's that), so I'd have to manually mark those as Done in the GitLab interface after reading them in my email.
Here's a link to the issue: https://gitlab.com/gitlab-org/gitlab-ee/issues/1951
I'll
They have, the Omnibus variant as well as the gitlab-ce docker container based on it includes Mattermost with integration. Just awesome, actually.
Add to that list that big diffs with many files (which are a bad practice, but do happen) causes the entire browser tab to freeze up.
Specifically, the person who signs off on Gitlab at a company is generally some kind of project manager so they value project management features.
Maybe it's worth the price. Did anybody used both of them and is willing to tell us how they compare?
I don't know exactly how GitHub Enterprise and the GitLab Community Edition compare in that regard but aspects such as usability, maintainability and updatability are much more important than saving $21 per user per month.
So, yes if your company has a lot fewer than 10 Git users GitLab probably is the best option. In every other case, it depends and the pricing advantage becomes less pronounced.
But for a petty price, Gitlab comes with a Kanban board, a release management system, a (free) CI tool, and all of the newer features I don't have experience with ( the whole Kubernetes integration lately? ). (So no need for paid travis, Asana, Jira, ....).
Adding to that that most cloud providers offer ready to use images with Gitlab installed, I understand what it becomes such a 'default choice' for new installs lately.
Our biggest customer installation had a serious problem in 2015 and we addressed it. We have customers switching from GHE because of the reliability of GitLab self hosted. There are problems on GitLab.com, we made solving that harder because we insist on running the same code our customers are running, so we'll never have a repeat of 2015.
We would love to get in touch to discuss any performance problems you're still having.
If that's the name of your employer, bear in mind that you can get into massive hot water for using it to endorse third-party products without authorization.
I was trying to say that, in my experience, Gitlab has become the defacto VCS tool for new/small companies that want something self-hosted.
What's interesting is, I do see the trend slightly change the last year, as Gitlab becomes heavier and people switching to gogs.
In the end there is probably enough space for all depending on your needs.
Today? The needs are different, and Git needs a better wrapper to do that. Thus, GL's emphasis on less code-centric (more PM-y) features.
- Reboot the UI (it isn't just changing existing, but replacing): https://jenkins.io/projects/blueocean/
- Getting rid of version numbers and updates, and fiddling with plugins by hand: https://jenkins.io/blog/2018/04/06/jenkins-essentials/ (make it ever green, like browsers)
- Jenkins X - which is really about how you build apps on Kubernetes: https://jenkins-x.io
- We also have https://CodeShip.com - for those that don't need the on-prem/self hosting flexibility/extensibility and want things to work as a service.
Its great to see so much activity in CI/CD these days, really cool to see. Hopefully if you run into Jenkins again one day in the future it wont be the one you have a bad memory of.
For example, GitLab CI/CD is far more useful to me than configurable tab width would ever be. It's not a basic code repo manager feature, but there's a clear reason why they're focusing on one more than the other.
I think gitlab are doing a pretty good job with their product.
Regarding batch review: We wanted to ship this way sooner. We spent an unfortunate amount of time refactoring our merge requests to use Vue. That is now done, so work on this has started and should be shipping on August 22nd, with GitLab 11.2. See also the epic on the subject: https://gitlab.com/groups/gitlab-org/-/epics/23
All the other issues you referenced should get appropriate priority. I recently made a change in what team is responsible for code review, so that we don't have to choose between code review and issue tracking features, but rather between different features related only to Git. This should help. (i.e. responsibility went from the 'Discussion' team to the 'Create' team).
Regarding viewing large diffs: we're working hard on a better solution. Follow the epic for the full picture: https://gitlab.com/groups/gitlab-org/-/epics/15
>To make these memory leaks manageable, GitLab comes with the unicorn-worker-killer gem. This gem monkey-patches the Unicorn workers to do a memory self-check after every 16 requests. If the memory of the Unicorn worker exceeds a pre-set limit then the worker process exits. *
I know this is a Rails issue, but I cannot believe this is still a problem. I remember when the RoR folks blamed the Rails memory leaks on Zed, and Mongrel, more than a decade ago. They were obviously incorrect. Did the community simply give up on fixing the problem?
* https://docs.gitlab.com/ee/administration/operations/unicorn...
After all, if the gc is not freeing the memory then it must know a reachable path to it so the blame should be easy to assign.
Does ruby not have any good heap profiling tool ?
If you have enough not-perfectly-cleanly-separated layers of data management interacting, then this gets hard to debug pretty fast.
I am very familiar with the rubyverse, and boy do I got news for you.
Rails is to Ruby as the Big Dig is to Boston.
But it's hard to get Rails devs to admit it. They know it, of course. They live it. They breathe bad code, they exist as extensions of a philosophy that has failed it's way to the top.
I used to think Zed was a dramatic weenie. Then I got a bit deeper in Rails to learn how to pursue better exploits. And deeper. And deeper. And finally I just hit a point where I just wasn't willing to work on RoR-related gigs.
Convention over configuration is one of those ideas that goes great on paper. And then you start in on some buzzwords and fancy lingo, it's the bread and butter of selling to project managers. But there is a point where CoC breaks down at a technical level, and that point is literally the first moment you come across something difficult to express
Rails is weak in doing things ANY other way than the Rails way, and what developers do (and it's not their fault) is using their creativity and ingenuity to solve the problem. I believe this is why metaprogramming in Ruby has such a vocal backing, because there are millions of shims holding up millions of Rails' shitty choices that depend on method_missing fuckery or string-based define_method gadgets. In the spirit of what it means to solve hacker-ish problems, it's great fun to program like that for a while, and then a year or two down the line you look at that shit and it can really break you down. Good developers mistake themselves for bad developers because of this, to be honest.
Zed's probably had the idea to write an entire book of how insanely FUCKED Rails actually is, but to make the book plausibly thorough would mean a human being being exposed to far more stupidity than modern science can safely treat for. It'd be dangerous to have that much stupid intake just for a book.
That unicorn-worker-killer gem is a perfect caricature of the kinda problem-solving you run into with Rails. Let it die a horrible death, restart that shit with some logic to let it keep dying predictably.
That technique, multiplied by every component in the system, multiplied by every developer on the team, multiplied by MVC requiring developers to have to know too broadly the system they're working on, multiplied by however many years and Rails versions the project has somehow survived, you approach something I can only imagine is quite similar to what hell must be.
Refactoring a large Ruby on Rails codebase is basically impossible. There's no compiler to help you along; hell the code is evaluated lazily. So instead of refactoring, people monkey-patch their problems away. It's horrible, really really horrible.
I'm now getting flashbacks to trying to understand how files get loaded in that codebase... I need a drink
As a concrete example on a small scale of something common such as renaming a model field name. Given that ActiveRecord reflects the database and generates the methods dynamically there’s pretty much no good way to refactor that field easily. It requires a lot of manual searching/filtering to find possible usages and then time on that to ensure it’s not a shared name on a different object type. From what I’ve seen in many code bases it ends up manifesting as `delegate` usage and often just expands the API exposed by the model.
Compare that to something compiled, or even something like python that doesn’t encourage meta too much, and you can pretty much find all symbol usages with whatever intellisense engine you prefer (ctags, JetBrains, jedi, ...)
I would give a kidney to have static compilation in rails when refactoring.
IMO, you can still learn tons of great practices with Rails, and for certain projects I still think it's a great choice... But you have to know when to drop it and move on to more robust solutions.
Like most engineering tools, it makes certain tradeoffs, and you have to know how to pick the right one for your job.
Rails is incredibly effective for solving the problems that existed at the time it was conceived. CRUD websites, rapid prototypes, things that aren't incredibly complex. Not an exhaustive list, but that's what I reach out to Rails for now.
Once you get past that certain point, not only does the framework fail to offer a convention for the problem you might face, but it also requires a mature team of developers to guide things forward from that point on, and really think about how to build something that Rails itself has no decent answer for. That solution might be to break out of Rails, or switch to raw SQL queries, or to proxy to services that can handle the task better. It's almost never a good idea to double down on the convention at that point.
> This is a robust way to handle memory leaks
Seriously wow.
It is a practical hands-on solution. However it’s also bad engineering. I too have used unicorn-killer and it was always the result of trying to make bad code not crash our servers. It is a lazy hack solution that I used because it was easy and at the time didn’t know enough to fix the actual issues. I was inexperienced. No disrespect intended but with the suggestion that essentially restarting the server is a robust strategy against memory leaks, it’s kind of hard to be confident of the technical robustness of the platform, especially at scale.
I can guarantee that Github isn’t using unicorn-killer nor blaming Ruby for performance issues.
I know we are supposed to be “Hurray Gitlab! Open core!” but it feels like GitLab support around here is contrived and astroturffed, by GitLab insiders. Any company that actually claims unicorn killer is a robust way to handle memory leaks has some extremely incompetent technical leadership. The robust way is to not to have memory leaks! Essentially restarting your servers all the time (which is what unicorn killer practically does) is a ridiculous way to handle memory leaks.
However, I have a special dislike for "convention over configuration". What that really means is: You must write code my style. As there is no configuration, it will be difficult to discover what that means by reading the code. You must study and memorise the one true way. If you deviate from it, strange things will probably happen and it will be your fault for not doing it my way.
To be fair, Rails documentation is really very good. Also, this is a selling point for the framework. If you give no choices then everybody must do it the same way. Even if that way is stupid. You can hire a whole bunch of people who "know rails" and they can struggle along and make progress. You don't have to trust them with decisions because the important decisions were already made for them.
I've had a wide and varied career before doing this work. It's hard for me accept "because it's the Rails Way" to questions like "Why are we doing this when it is causing problems?" I don't mind people making mistakes as long as it is not a thoughtless mistake. "I thought this would work, but I was wrong", is a wonderful sentence in my book. Unfortunately that's the kind of action that many programmers are dissuaded from taking -- instead they are encouraged to do it the "Rails Way".
Lots of beginning programmers also prefer it this way. When you are first starting out (and... well... even when you've been doing it for a couple of decades) it's hard to know which way is better. You might even have a preference, but then struggle greatly when someone asks "Why is that better". Especially beginning programmers often get stuck without knowing any way to accomplish something. In those cases, the "Rails Way" is extremely comforting. 1) It's a way. 2) It will probably work (at least grossly) 3) Famous people say it's good, so it's very, very comforting to agree. People entrenched in the community reinforce each other until it seems practically impossible that there might be a better way. But they may not have looked.
Of course Rails is not the only "Way" out there that espouses these ideas. It's just a currently popular one. What's really at fault is the "convention over configuration" attitude -- Don't think; just do it my way. I hate that.
I think this is a dangerous line of thinking. This crosses the line of being productively critical of a language or a framework into actually attacking people.
By promoting this line of thinking, you increase the tolerance of this kind of attack.
People arrive at their personal choice of language and framework as a function of their environment, their education, their first job, what's popular at the time, and myriad of other factors.
I am sure you have preferences for languages and frameworks, and I'm sure there are other people who don't agree with them. Do you want those people giving you reasoned arguments about why you should change your preferences or, do what you did, make allusions that you are so irredeemably stupid that you physically exhale shoddy code?
Being able to review per commit in a merge request was a major reason for my company to choose gitlab back in the day. A merge request consists of a series of commits, each doing a single change (basically the same way linux's patch series works: https://www.kernel.org/doc/html/v4.16/process/submitting-pat...).
I'm hoping gitlab will improve the experience in the future for us that want patch series style merge requests, but I'm worried that gerrit style development is winning where the result of each merge request is supposed to be just a single squashed commit.
With the irrelevant information, you mean the top part of the merge requests (ie description, CI status, etc)?
And as far as I can see, in the current version, we only hide the body part of the commit message.
I think we can make the experience better by autoscrolling down once you click on a commit in a merge request. I've made an issue [0].
I'm not sure about showing the full commit message. Many would argue that only the first line summary is crucial to show, which is what we do now. But I'm happy to discuss.
This might be a difference in expectations, where we are talking about two styles of merge requests. I believe they can be both supported well by gitlab (in fact, I consider gitlab to be the best review tool out there because it has support for both styles).
## Gerrit style MR
Mostly a merge request with a single commit. All relevant information is placed in MR title/description. If there are more than one commits, they are usually added to review the first commit based on review feedback or problems detected by CI. The commits are often squashed before merge to master, so the individual commit messages are secondary to the MR title/description.
## Patch series style MR
A merge requests with multiple commits, each containing a single logical change. The MR title/description only contains high level information/summary - more detailed description is found in the commits.
If serious problems are found either by CI or reviewer, the developer often amends the commits rather than push new commits on top. The reason why is that each commit should be as complete as possible, which helps reviewing, git bisect and keeping a good git log history.
This style requires more upfront work by the developer, but the advantage is that reviewing becomes easier. Instead of reviewing a large diff with many different changes, the reviewer can look at a single commit at a time. Some types of changes such as refactor, reformat can quickly be verified and reviewed because they are not making any semantics changes. A commit containing a bug fix is much quicker to review if there are no refactoring, reformating or other semantic changes in the same diff.
Good commits should also have good commit messages, which describes what, why and why like /this/. Just as important, this information should be easily available when reviewing the merge request. It should be easy to iterate through all the commits in a merge request, reviewing both the commit message and the commit diff for each commit.
With the latest changes of gitlab, I feel it's being optimized for Gerrit style merge requests, in which case your comment make sense that you're not sure about showing the full commit message. However, for me this is a major step back since we do patch series style merge requests where each commit is often reviewed individually.
I created an issue on this and I encourage you to contribute there as well: https://gitlab.com/gitlab-org/gitlab-ce/issues/48334
We're not fans of adding additional configuration, but I can imagine we store e.g. what the last state was that you left commit message in, as to not have to unfold it every time. I'm sure you have further thoughts on improvements that can be made.
The exact commit is as follows:
libobs: Add scene item grouping
Allows the ability to group scene items. Groups
internally are sub-scenes, which allows the ability to
add unique filters and transforms to each group.
This is all personal preference though...
1. Lack of traceability/auditability. We're in healthcare, and have a regulatory burden that requires versioning of basically everything. GitLab does this for code and wikis (thanks to git itself) but not for issues, merge requests, comments, etc. I've ended up building a service that just ingests the webhooks for these to store them away, which feels ridiculous. Since the webhooks for comments doesn't get triggered on update, I even have a TRIGGER shimmed into GitLab's postgres DB. Ech.
2. There's no concept of a bot user, so every integration we want to do is against a single account/identity, in part because...
3. The pricing of Ultimate feels ridiculous, and that's the only way to get something as fundamental as epics. $1000+ a year for every employee?
[edit] $1000/mo -> $1000/yr. (per month would have been even more way cray)
Typo? Pricing page [1] lists it at $99/mo
1. I'd love to see everything versioned in GitLab. We're working on the issue descriptions, but I agree we should move toward versioning everything. There's an epic here [0], that we will be filling out with more issues to address what we haven't yet. Feel free to leave feedback there as well.
2. Most integrations are against projects, groups or instances. For those that require an acting agent, I recommend just creating a normal account for that and call it bot. I think it makes sense for us to have some sort of permanent solution for bots [1]. In the meantime, I propose you talk with our sales team about that. I'm sure they're willing to be flexible.
3. We believe the pricing for Ultimate is fair, given the broad range of tools GitLab replaces, from project management, to CI, to security, licensing and container management tools. That said, we're aware that it's challenging to see the value for every single user. With this release we're taking a step that hopefully helps out, by making guest users free for Ultimate [2]. We welcome further feedback on how we can make GitLab even more accessible to everyone in the organisation.
[0]: https://gitlab.com/groups/gitlab-org/-/epics/237
[1]: https://gitlab.com/gitlab-org/gitlab-ee/issues/6600
[2]: https://about.gitlab.com/2018/06/22/gitlab-11-0-released/#un...
It would be nice to work with an existing project than roll your own.
My other big wish for the product is better CI. Gitlab certainly makes Travis unnecessary, but it doesn't scratch the surface of the functionality that Jenkins provides via the plugin ecosystem. Yes Jenkins is janky (although can be made to look nice enough via themes) - but Gitlab doesn't even address parsing xunit results and displaying trends in a project centric reporting location (https://gitlab.com/gitlab-org/gitlab-ce/issues/17081), instead steering you towards build centric "pages". Get the reporting built out (and also allow it to natively consume/parse/understand output from major testing & static analysis frameworks), and it would be a more compelling alternative. Nobody wants to look at hundreds or thousands of lines of build/test output - the CI tool should summarize the reasons for success or failure.
Finally, we're having to run our self-hosted Gitlab on an absurdly large EC2 instance (8 cores, 32GBs). Occasionally we'll have a dozen people converge on a single important PR for review, and before upgrading to our current server this type of event would often bring our instance to its knees. Language choice may be a significant contributor to this -- rewriting major parts of the backend in Go or some JVM language would probably be a good product goal.
GitLab now runs a copy of the rails stack under Gitaly because the git Go libraries don't support everything GitLab needs. So ironically moving to Go caused GitLab to use more memory. This will be fixed in Gitaly 1.1. There is no due date for that.
- Splitting the admin settings into multiple sub-pages to make it easier to visually parse (https://gitlab.com/gitlab-org/gitlab-ce/issues/44998)
- Adding search for settings pages (https://gitlab.com/gitlab-org/gitlab-ce/issues/41112)
- Prioritizing content on settings pages (https://gitlab.com/gitlab-org/gitlab-ce/issues/47405)
The UX team has an epic on these improvements (https://gitlab.com/groups/gitlab-org/-/epics/203), grateful for any feedback on specific issues. Thanks for pushing us here to improve.
GitLab collects information about usage from each self-hosted GitLab instance (Community Edition and Enterprise Edition) through a usage ping. The usage ping sends a payload containing data such as total number of projects and pipelines, as well as license information and hostname to GitLab.
...
The information from the usage ping is not anonymous, it is linked to the hostname of the instance [3]
...
The documentation is a merge request [4]
This MR loads the EE usage ping asynchronously on the admin application settings page and now includes the counts of the following items:
Comments Groups Users Projects Issues Labels CI builds Snippets Milestones Todos Pushes Merge requests Environments Triggers Deploy keys Pages Project Services Issue Boards CI Runners Deployments Geo Nodes LDAP Groups LDAP Keys LDAP Users LFS objects Protected branches Releases Remote mirrors Web hooks
[1]https://about.gitlab.com/privacy/ [2]https://about.gitlab.com/terms/ [3]https://docs.gitlab.com/ee/user/admin_area/settings/usage_st... [4]https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/735
that statement is wrong. first of all IP Addresses are only PII if you store them to identify users, means that if you are user table has an ip_address field, it is, however... if you store all ip's accessing your service in a database to find malicious logins it isn't. so basically the statement is, it depends. the connection of user to ip makes it PII.
Aside from monorepos there is one other small issue I have with GitLab. GitLab is perfectly well situated to completely take over the software development planning, warehousing, deployment, and testing. Documentation is really the last front. If GitLab wikis were as powerful as Confluence I would be very happy because I'd never need to use that terrible bloated site ever again. I've been pushing for us to switch to GitLab wikis for a while but 2 coworkers keep saying that "it is not good for long-lived out-of-project documentation, it's not as searchable, you can't drag and drop for graphs, it's not as integrate, and it doesn't have as many features as Confluence".
I hope one day GitLab can be my one-stop-shop for everything.
Thank you very much for making such an amazing product.
Regarding the documentation we see many people switching to static websites generated with GitLab pages. This allows you to separate the change from the approval. Is this an option for you?
My coworkers are concerned with the following:
- Highlight and right click docs -> new ticket
- Drag and drop flow chart creation
- Non-developers can document and plan
- Full text search
- "Name spaced"/grouped documentation
- Third party integrationFor non developers you can make it easier to edit by linking the bottom of each page to the reposity. See our website or docs pages for an example of that.
If linked_mr:
print "warning, merging this will also merge:" + linked_mr
...
Function merge()
...
if linked_mr:
merge(linked_mr)
(+) by data I don't mean the repo itself, but all the data around it (issues, project management stuff, etc).
Either the entire thread is loves it (for the most part), or the entire thread hates it (for the most part).
shrugs
Otherwise it’s usually at least some or majority love for Gitlab on HN.
Most of the time, it is all love.
No, I'm not joking. I've had the omnibus package break my Gitlab as well and the bugs survived even full reconfigures and restarts. Rebooting the server fixed it even though it makes no sense.
gitlab-ctl reconfigure && gitlab-ctl restart