10 ms·

GitLab 9.3 released

161 points by markdog12 9y ago

LukaD 9y ago
What is the deal with features being exclusives to EEP? I really hate that. I want those features but I don't want the EEP support. I can't justify paying 5 times as much just for those features.
- Sir_Substance 9y ago
  A compromise to make money. Gitlab keeps features it thinks that really only enterprise users need restricted to the EEP, on the basis that enterprises really should be able to afford to pay, and their payments improve the product for everyone. Gitlab seems to be pretty open to discussing the possibility of moving features into CE. I don't not for sure, but my guess is that they try to keep a certain number of EEP-only features to make sure that sysadmins can justify the EEP on the balance sheet, and then move as much else as they can to CE. If you really think a specific feature is of interest to non-enterprise customers, you should go to their designated feedback location (don't know what it is) and make a reasoned argument as to why that feature is needed by non-enterprise customers.
  - Snappy 9y ago
    A new issue on the CE issue tracker is usually the best place. https://gitlab.com/gitlab-org/gitlab-ce/issues/new https://gitlab.com/gitlab-org/gitlab-ce/issues/new
sverhagen 9y ago
I've watched the video, this afternoon, and I'm wondering if these build pipelines are trying to service the same space as Spinnaker does?
- markdog12 9y ago
  There's a lot of companies in that space, but yes, Gitlab is aiming to be the total package when it comes to development. "Idea, Issue, Plan, Code, Commit, Test, Review, Staging, Production, Feedback". Deployment is a part of that. I don't know much about Spinnaker, but it seems to have more features than Gitlab at the moment, although Gitlab adds features at a decent pace (release on the 22nd of every month).
  - sytse 9y ago
    That is indeed our plan. We already have canary deploys and autoscaling. There are more ops features planned: https://gitlab.com/gitlab-org/gitlab-ee/issues/2412 https://gitlab.com/gitlab-org/gitlab-ee/issues/2412
    - markdog12 9y ago
      Thanks for GitLab and the helpful link. It's also nice to see you're keeping https://about.gitlab.com/direction/ https://about.gitlab.com/direction/ up to date. Lots of nice stuff in there, including ops features.
      - sytse 9y ago
        You're welcome. And thanks for linking /direction. We auto generate it via our API so it is always up to date.
sashk 9y ago
Good release, but... I'm getting frustrated of inconsistencies in UI (example -- issue filtering was re-designed in 9.x, but merge requests are still old; search for issues in multiple projects -- old). Unexpected changes, which break existing workflows (un-announced), and so on... They pushing for new features, but forget to fix old bugs. There are couple of bugs open for months, even with existing merge request to fix -- nobody from engineers take a look until pushed by someone of paying customers. I hope, Gitlab can pull "Snow Leopard" and do bug-fix only release, and repeat it couple times a year.
- a012 9y ago
  I feel like they're pushing hard, so there're more new things to track/change. Last time I installed a local gitlab community server was 8.something, and it's just last year. I understand why my current company just keep local gitlab at older version (V8 I guess).
- jakecodes 9y ago
  @sashk Thanks for the feedback. Your feedback, and others has been heard loud and clear and we've been hard at work this next month. For next month's release (9.4) we were able to tackle just about 100 UI polish bugs. New systems are being put into place to make sure we are polished right out the door, and that the UI is consistent. We want you to love our UI.
  - orf 9y ago
    Not sure if this has been added to the bug tracker, but when your creating a merge request, clicking the two branches and bringing up the selection boxes used to focus them so you could type into the search straight away. It no longer does, so it needs two extra clicks. It's small stuff like this that is quite annoying. Great release though, especially with the container registry fixes.
    - cmatija 9y ago
      Thanks for pointing this out. I opened a new issue about this; here https://gitlab.com/gitlab-org/gitlab-ce/issues/34246 https://gitlab.com/gitlab-org/gitlab-ce/issues/34246
imroot 9y ago
I love Gitlab: both the product and the company. I really do. With that said, I was really kinda upset that they enabled "Delete Merged Branch" by default in the last major release (9.2): it really caused a few days of headaches of reverting development/staging branches that developers and merge approvers approved. I ended up writing a small Chrome plugin to uncheck the box, and distributed it to the developers that I work with before going in and learning enough angular to disable the box from being checked by default. Sid; I have nothing but respect for you and the rest of gitlab, but, please don't change the behavior of how gitlab works (and yes, I understand convention over configuration) without giving either project or site administrators the ability to disable those changes.
- markdog12 9y ago
  I would think it's a sensible default, but you're right, you should have the option to change it. I actually assumed the option was there, but I just checked in 9.3, and it's not.
  - sytse 9y ago
    I'm sorry to hear it caused problems. I think we can maybe make the behavior more intelligent, it should not delete longer running branches by default. We are very reluctant to add options to GitLab as detailed in point 11 of the acceptance criteria of our contributing guide https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU... But if we can't make the behavior more intelligent we will probably have to add an option.
    - Aeolun 9y ago
      To give a different perspective. I always forgot to check the box, and now noticed a significant decrease in randomly left over branches. So it's working out pretty well for me.
      - slavik81 9y ago
zeckalpha 9y ago
I'm most impressed with https://docs.gitlab.com/ee/user/admin_area/monitoring/convdev.html https://docs.gitlab.com/ee/user/admin_area/monitoring/convde... This is a game changer.
- witten 9y ago
  I honestly don't get the feature. More issues created per user == better? That's like more lines of code == better. Could you explain how this is a game changer for you?
  - ntwrkguru 9y ago
    For me, it means that there's more feedback and improvement being suggested.
- sytse 9y ago
  Glad to hear that. Can you maybe tell more about your use case?
  - zeckalpha 9y ago
    Lowering cycle time to production, streamlining delivery of value to customers, validating more hypotheses against the market?
    - sytse 9y ago
      Cool! Thanks
elktea 9y ago
https://docs.gitlab.com/ee/user/project/merge_requests/code_quality_diff.html https://docs.gitlab.com/ee/user/project/merge_requests/code_... Is code climate a free product or paid only?
- gtirloni 9y ago
  https://codeclimate.com/pricing https://codeclimate.com/pricing
- sytse 9y ago
  Code quality is based on the open source code of code climate but it is a feature available only in enterprise edition.
jhasse 9y ago
It seems that you brought the sticky/fixed header back. Why? :(
- cmatija 9y ago
  Here's the MR where that got implemented, so you can get a bit more context on it https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10751 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10751
romanovcode 9y ago
IMO GitLab should seriously stop with the features and spend more time in making the UI look decent and aesthetically pleasing.
- danpalmer 9y ago
  Yeah. The features are impressive but I find the interface difficult to scan. GitHub is far more legible, but I find the additional time to scan UIs and text on GitLab just makes the whole experience slower and less pleasant.
  - romanovcode 9y ago
    Yeah, GitLab already "won" on the features. But it doesn't matter when they lose so much on the design.
- CameronBanga 9y ago
  The biggest UI issue they have is the CONSTANT change. It seems like every single month, I need to learn a new UI workflow. Improvement is good, but there is such thing as too much change.
  - svesselov 9y ago
    This is a valid point. We are doing all that we can to balance making substantial UI improvements while not making disruptive changes the flows.
- mydigitalself 9y ago
  Hi there. This is something we are actively working on as part of overhauling the entire UI hierarchy. You can follow the main issue here: https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 Feel free to let us know your thoughts. This will start making it's way into the application in 9.4 (July) and will be activated through a feature toggle so people can experiment with the new UI, give us feedback and we'll iterate and improve it before we switch it over.
- 9y ago
xmatos 9y ago
GitLab's CI runs on every branch push, which I dislike, since you can push a branch that isn't ready yet for backup purposes. Although, it can be configured to automatically deploy only to staging, while having production deployment manually triggered. It can also run only on specific branches, like staging and master. I was after a way to integrate deployment with task status updates, so once we updated a task status to Staging, for example, it would trigger a job to merge that task's feature branch to staging and deploy it. Once it gets tested and approved, we would update the task status to Approved, which would trigger a master merge and a push to production. To me, this would be the perfect solution. Unfortunately, that's not how it works. It might be achievable through GitLab's web hooks and api, but i don't think it has a way to add a custom field to a task to store the related git branches and it only has an open / close status. We could use labels instead and parse the task description to extract the branch info. What I've done in the past and worked great is use git hooks for deployment. That would handle deployment's heavy lift, but I'd still like to automate branch merging, by linking it to task status. Has anyone done that? Is it a good idea? Are there any caveats? Any tips or ideas would be highly appeciated. Thanks!
- wibbleywobbley 9y ago
  >GitLab's CI runs on every branch push, which I dislike, since you can push a branch that isn't ready yet for backup purposes. What's the downside of deploying a review app for something that's "not ready"? It's (presumably) just deploying to a development-only environment of some kind anyway. I'd also argue that you should be pushing almost as regularly as you commit. It increases the opportunity for discussion of what you are working on and it's also useful to know "does this still successfully deploy?" Here's an excerpt of a .gitlab-ci.yml file from one of my projects: https://gist.github.com/kelchm/fc8ca06dd3e44a42fa640ed7a8e8429e https://gist.github.com/kelchm/fc8ca06dd3e44a42fa640ed7a8e84... Basically, the functionality is as follows: 1. Any branch other than 'master' automatically deploys to a development environment (AKA a 'Review App'). Multiple of these review apps can exist in the development environment. 2. Merges into master are automatically deployed to staging 3. Tags which match the form '/^v.*$/' are considered production releases and result in a manual deploy job being created. It's a really simple and powerful workflow.
- 9y ago

161 points by markdog12 9y ago

What is the deal with features being exclusives to EEP? I really hate that. I want those features but I don't want the EEP support. I can't justify paying 5 times as much just for those features.

Sir_Substance 9y ago
A compromise to make money. Gitlab keeps features it thinks that really only enterprise users need restricted to the EEP, on the basis that enterprises really should be able to afford to pay, and their payments improve the product for everyone. Gitlab seems to be pretty open to discussing the possibility of moving features into CE. I don't not for sure, but my guess is that they try to keep a certain number of EEP-only features to make sure that sysadmins can justify the EEP on the balance sheet, and then move as much else as they can to CE. If you really think a specific feature is of interest to non-enterprise customers, you should go to their designated feedback location (don't know what it is) and make a reasoned argument as to why that feature is needed by non-enterprise customers.
- Snappy 9y ago
  A new issue on the CE issue tracker is usually the best place. https://gitlab.com/gitlab-org/gitlab-ce/issues/new https://gitlab.com/gitlab-org/gitlab-ce/issues/new

sverhagen 9y ago

I've watched the video, this afternoon, and I'm wondering if these build pipelines are trying to service the same space as Spinnaker does?

markdog12 9y ago
There's a lot of companies in that space, but yes, Gitlab is aiming to be the total package when it comes to development. "Idea, Issue, Plan, Code, Commit, Test, Review, Staging, Production, Feedback". Deployment is a part of that. I don't know much about Spinnaker, but it seems to have more features than Gitlab at the moment, although Gitlab adds features at a decent pace (release on the 22nd of every month).
- sytse 9y ago
  That is indeed our plan. We already have canary deploys and autoscaling. There are more ops features planned: https://gitlab.com/gitlab-org/gitlab-ee/issues/2412 https://gitlab.com/gitlab-org/gitlab-ee/issues/2412
  - markdog12 9y ago
    Thanks for GitLab and the helpful link. It's also nice to see you're keeping https://about.gitlab.com/direction/ https://about.gitlab.com/direction/ up to date. Lots of nice stuff in there, including ops features.
    - sytse 9y ago
      You're welcome. And thanks for linking /direction. We auto generate it via our API so it is always up to date.

sashk 9y ago

Good release, but... I'm getting frustrated of inconsistencies in UI (example -- issue filtering was re-designed in 9.x, but merge requests are still old; search for issues in multiple projects -- old). Unexpected changes, which break existing workflows (un-announced), and so on... They pushing for new features, but forget to fix old bugs. There are couple of bugs open for months, even with existing merge request to fix -- nobody from engineers take a look until pushed by someone of paying customers. I hope, Gitlab can pull "Snow Leopard" and do bug-fix only release, and repeat it couple times a year.

a012 9y ago
I feel like they're pushing hard, so there're more new things to track/change. Last time I installed a local gitlab community server was 8.something, and it's just last year. I understand why my current company just keep local gitlab at older version (V8 I guess).
jakecodes 9y ago
@sashk Thanks for the feedback. Your feedback, and others has been heard loud and clear and we've been hard at work this next month. For next month's release (9.4) we were able to tackle just about 100 UI polish bugs. New systems are being put into place to make sure we are polished right out the door, and that the UI is consistent. We want you to love our UI.
- orf 9y ago
  Not sure if this has been added to the bug tracker, but when your creating a merge request, clicking the two branches and bringing up the selection boxes used to focus them so you could type into the search straight away. It no longer does, so it needs two extra clicks. It's small stuff like this that is quite annoying. Great release though, especially with the container registry fixes.
  - cmatija 9y ago
    Thanks for pointing this out. I opened a new issue about this; here https://gitlab.com/gitlab-org/gitlab-ce/issues/34246 https://gitlab.com/gitlab-org/gitlab-ce/issues/34246

imroot 9y ago

I love Gitlab: both the product and the company. I really do. With that said, I was really kinda upset that they enabled "Delete Merged Branch" by default in the last major release (9.2): it really caused a few days of headaches of reverting development/staging branches that developers and merge approvers approved. I ended up writing a small Chrome plugin to uncheck the box, and distributed it to the developers that I work with before going in and learning enough angular to disable the box from being checked by default. Sid; I have nothing but respect for you and the rest of gitlab, but, please don't change the behavior of how gitlab works (and yes, I understand convention over configuration) without giving either project or site administrators the ability to disable those changes.

markdog12 9y ago
I would think it's a sensible default, but you're right, you should have the option to change it. I actually assumed the option was there, but I just checked in 9.3, and it's not.
- sytse 9y ago
  I'm sorry to hear it caused problems. I think we can maybe make the behavior more intelligent, it should not delete longer running branches by default. We are very reluctant to add options to GitLab as detailed in point 11 of the acceptance criteria of our contributing guide https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU... But if we can't make the behavior more intelligent we will probably have to add an option.
  - Aeolun 9y ago
    To give a different perspective. I always forgot to check the box, and now noticed a significant decrease in randomly left over branches. So it's working out pretty well for me.
    - slavik81 9y ago

zeckalpha 9y ago

I'm most impressed with https://docs.gitlab.com/ee/user/admin_area/monitoring/convdev.html https://docs.gitlab.com/ee/user/admin_area/monitoring/convde... This is a game changer.

witten 9y ago
I honestly don't get the feature. More issues created per user == better? That's like more lines of code == better. Could you explain how this is a game changer for you?
- ntwrkguru 9y ago
  For me, it means that there's more feedback and improvement being suggested.
sytse 9y ago
Glad to hear that. Can you maybe tell more about your use case?
- zeckalpha 9y ago
  Lowering cycle time to production, streamlining delivery of value to customers, validating more hypotheses against the market?
  - sytse 9y ago
    Cool! Thanks

elktea 9y ago

https://docs.gitlab.com/ee/user/project/merge_requests/code_quality_diff.html https://docs.gitlab.com/ee/user/project/merge_requests/code_... Is code climate a free product or paid only?

gtirloni 9y ago
https://codeclimate.com/pricing https://codeclimate.com/pricing
sytse 9y ago
Code quality is based on the open source code of code climate but it is a feature available only in enterprise edition.

jhasse 9y ago

It seems that you brought the sticky/fixed header back. Why? :(

cmatija 9y ago
Here's the MR where that got implemented, so you can get a bit more context on it https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10751 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10751

romanovcode 9y ago

IMO GitLab should seriously stop with the features and spend more time in making the UI look decent and aesthetically pleasing.

danpalmer 9y ago
Yeah. The features are impressive but I find the interface difficult to scan. GitHub is far more legible, but I find the additional time to scan UIs and text on GitLab just makes the whole experience slower and less pleasant.
- romanovcode 9y ago
  Yeah, GitLab already "won" on the features. But it doesn't matter when they lose so much on the design.
CameronBanga 9y ago
The biggest UI issue they have is the CONSTANT change. It seems like every single month, I need to learn a new UI workflow. Improvement is good, but there is such thing as too much change.
- svesselov 9y ago
  This is a valid point. We are doing all that we can to balance making substantial UI improvements while not making disruptive changes the flows.
mydigitalself 9y ago
Hi there. This is something we are actively working on as part of overhauling the entire UI hierarchy. You can follow the main issue here: https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 https://gitlab.com/gitlab-org/gitlab-ce/issues/32794 Feel free to let us know your thoughts. This will start making it's way into the application in 9.4 (July) and will be activated through a feature toggle so people can experiment with the new UI, give us feedback and we'll iterate and improve it before we switch it over.
9y ago

xmatos 9y ago

GitLab's CI runs on every branch push, which I dislike, since you can push a branch that isn't ready yet for backup purposes. Although, it can be configured to automatically deploy only to staging, while having production deployment manually triggered. It can also run only on specific branches, like staging and master. I was after a way to integrate deployment with task status updates, so once we updated a task status to Staging, for example, it would trigger a job to merge that task's feature branch to staging and deploy it. Once it gets tested and approved, we would update the task status to Approved, which would trigger a master merge and a push to production. To me, this would be the perfect solution. Unfortunately, that's not how it works. It might be achievable through GitLab's web hooks and api, but i don't think it has a way to add a custom field to a task to store the related git branches and it only has an open / close status. We could use labels instead and parse the task description to extract the branch info. What I've done in the past and worked great is use git hooks for deployment. That would handle deployment's heavy lift, but I'd still like to automate branch merging, by linking it to task status. Has anyone done that? Is it a good idea? Are there any caveats? Any tips or ideas would be highly appeciated. Thanks!

wibbleywobbley 9y ago
>GitLab's CI runs on every branch push, which I dislike, since you can push a branch that isn't ready yet for backup purposes. What's the downside of deploying a review app for something that's "not ready"? It's (presumably) just deploying to a development-only environment of some kind anyway. I'd also argue that you should be pushing almost as regularly as you commit. It increases the opportunity for discussion of what you are working on and it's also useful to know "does this still successfully deploy?" Here's an excerpt of a .gitlab-ci.yml file from one of my projects: https://gist.github.com/kelchm/fc8ca06dd3e44a42fa640ed7a8e8429e https://gist.github.com/kelchm/fc8ca06dd3e44a42fa640ed7a8e84... Basically, the functionality is as follows: 1. Any branch other than 'master' automatically deploys to a development environment (AKA a 'Review App'). Multiple of these review apps can exist in the development environment. 2. Merges into master are automatically deployed to staging 3. Tags which match the form '/^v.*$/' are considered production releases and result in a manual deploy job being created. It's a really simple and powerful workflow.
9y ago