GitLab 9.3 released(about.gitlab.com)
about.gitlab.com
GitLab 9.3 released
https://about.gitlab.com/2017/06/22/gitlab-9-3-released/
67 comments
@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.
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.
It's small stuff like this that is quite annoying. Great release though, especially with the container registry fixes.
Thanks for pointing this out.
I opened a new issue about this; here https://gitlab.com/gitlab-org/gitlab-ce/issues/34246
I’d like to report a few issues with the docker containers you provide – currently they don’t run at all, because they claim to require privileged access to several things? It’s not ideal (I’m trying to run GitLab CE on kubernetes, but I’ll likely have to modify it myself anyway to add OIDC login)
Our Docker images source is stored in our omnibus repo [1].
We also have docs detailing the usage of our Docker images. [2]
[1] - https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/doc...
[2] - https://docs.gitlab.com/omnibus/docker/
[1] - https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/doc...
[2] - https://docs.gitlab.com/omnibus/docker/
Yes, I know. I’ve deployed them, and they crash. While following your full instructions. Because tzdata isn’t writable.
Hi Kuschku,
Thanks for the feedback. Our current Docker container does require root because it is based on our Omnibus packages.
We are working to create a set of lean containers, one for each GitLab service (Sidekiq, Unicorn, Gitaly, etc.), which will no longer require root access.
More details are available in the issue that is tracking this effort: https://gitlab.com/charts/charts.gitlab.io/issues/14
Thanks for the feedback. Our current Docker container does require root because it is based on our Omnibus packages.
We are working to create a set of lean containers, one for each GitLab service (Sidekiq, Unicorn, Gitaly, etc.), which will no longer require root access.
More details are available in the issue that is tracking this effort: https://gitlab.com/charts/charts.gitlab.io/issues/14
Ah, okay, thanks. That explains my issue with running it on kubernetes. I'll look at that issue.
I'm also getting frustrated from Gitlab. My company has been on gitlab EE for over a year, and while they have pushed out features quite quickly, their UX is still way behind github. I think they don't have a laser focus on the user and spread themselves thin. There are basic user flows that lack the polish; for example merge requests actually are a pain to edit. If you click the edit button, it does a full page load (instead of doing it using ajax) and the page takes a few seconds to load. So trivial things like fixing the title because of a typo or changing the assignee are actually quite painful. They've hacked a solution by allowing you to some changes through back slash commands but it's still a hack that doesn't address the core problem. Even things like finding all the merge requests where you are listed as an approver is a pain. We have an internal Q&A site and the running joke is that every new hire during onboarding asks the same question "How do I find all open merge requests where I'm the approver" and the answer is always "we don't know". If took them a while to even notify you when your merge request was approved (so you could merge it). Just basic, basic UX is completely unaddressed while they roll out big features like burn down charts, todos, boards. Keep is simple stupid.
It's sad because I want gitlab to win (I believe in both their remote and open source approach) but Github's UX is so much better. We just acquired a company that uses Github so now we have a few engineers using both tools side by side and they all prefer Github's UX at this point so we might switch.
It's sad because I want gitlab to win (I believe in both their remote and open source approach) but Github's UX is so much better. We just acquired a company that uses Github so now we have a few engineers using both tools side by side and they all prefer Github's UX at this point so we might switch.
> their UX is still way behind github. I think they don't have a laser focus on the user and spread themselves thin. There are basic user flows that lack the polish
Using both regularly, the whole create issue 1234-> autocreate branch+MR -> git fetch+checkout 1234<TAB> -> code -> git push -> review -> resolve discussions+open issues for unresolved -> merge+autoclose+autoremove branch -> git fetch --prune flow is downright awesome† and really acted as a catalyst. GitHub just feels so antiquated and cranky compared to that so depending on what you're looking for this frustration can definitely go both ways.
† and it'll be even more awesome when we will soon enable per-branch review deployments which get auto-destroyed on branch removal, followed by auto-deploy of master in staging + manual in production, all neatly tracked in the environments tab.
Using both regularly, the whole create issue 1234-> autocreate branch+MR -> git fetch+checkout 1234<TAB> -> code -> git push -> review -> resolve discussions+open issues for unresolved -> merge+autoclose+autoremove branch -> git fetch --prune flow is downright awesome† and really acted as a catalyst. GitHub just feels so antiquated and cranky compared to that so depending on what you're looking for this frustration can definitely go both ways.
† and it'll be even more awesome when we will soon enable per-branch review deployments which get auto-destroyed on branch removal, followed by auto-deploy of master in staging + manual in production, all neatly tracked in the environments tab.
I don't think Github are looking to implement the whole CI process.
They want to host code and integrate neatly with other CI providers.
I think that makes much more sense (why abandon Travis or Heroku for the sake of having "one" platform to rule them all... ?)
They want to host code and integrate neatly with other CI providers.
I think that makes much more sense (why abandon Travis or Heroku for the sake of having "one" platform to rule them all... ?)
Hi there, thanks for the feedback.
Our UX team has grown considerably recently and this is a big area of focus for us.
In addition to small UX improvements all over the product, we are also doing a massive overhaul to the overall navigation of GitLab starting in 9.4. This work will continue behind a feature toggle for a couple of releases. You can see the work here (https://gitlab.com/gitlab-org/gitlab-ce/issues/32794) and, as always we'd love to hear your thoughts on it, free to ping me directly in that issue on @mydigitalself to discuss.
Our UX team has grown considerably recently and this is a big area of focus for us.
In addition to small UX improvements all over the product, we are also doing a massive overhaul to the overall navigation of GitLab starting in 9.4. This work will continue behind a feature toggle for a couple of releases. You can see the work here (https://gitlab.com/gitlab-org/gitlab-ce/issues/32794) and, as always we'd love to hear your thoughts on it, free to ping me directly in that issue on @mydigitalself to discuss.
> merge requests actually are a pain to edit.
Thank you for the feedback. We are actively working on making the merge request flow faster and easier to use. We have set up a round of user research to get insight into what works, doesn't work, and how we can make it better. Questions like: >"How do I find all open merge requests where I'm the approver" should be easy to answer and we are working on making that happen.
I would love to have your insights as part of our ongoing research. If you are interested, you can sign up to participate here:
https://about.gitlab.com/researchpanel/
Thank you for the feedback. We are actively working on making the merge request flow faster and easier to use. We have set up a round of user research to get insight into what works, doesn't work, and how we can make it better. Questions like: >"How do I find all open merge requests where I'm the approver" should be easy to answer and we are working on making that happen.
I would love to have your insights as part of our ongoing research. If you are interested, you can sign up to participate here:
https://about.gitlab.com/researchpanel/
Thanks for the feedback regarding editing merge requests. In this release, we brought inline editing to issues. (So you don't have to do a full page load, like you mentioned.) So we will definitely bring this concept to merge requests at a later release.
Regarding searching by approvers, we definitely recognize it's a common flow. And we've documented it in an issue. https://gitlab.com/gitlab-org/gitlab-ee/issues/1951. We hope to work on it soon.
Regarding searching by approvers, we definitely recognize it's a common flow. And we've documented it in an issue. https://gitlab.com/gitlab-org/gitlab-ee/issues/1951. We hope to work on it soon.
Inline editing is important design direction we are heading toward. The benefit is that you don't have to reload the entire page. And of course you can do single tasks, like updating labels / milestones / titles / descriptions all independently and separately, providing a more web-app-like experience, instead of a website experience. Ultimately, it's more usable and efficient.
In particular for the issue / merge request description areas, we want to get to a more collaborative design in the future when you can see other users making changes in super near-real-time, almost like Google docs. Currently, our issue descriptions already are updated in real-time, but it takes a few seconds for you to see updates. So we are working hard in this direction and we appreciate the validation that inline editing makes sense.
In particular for the issue / merge request description areas, we want to get to a more collaborative design in the future when you can see other users making changes in super near-real-time, almost like Google docs. Currently, our issue descriptions already are updated in real-time, but it takes a few seconds for you to see updates. So we are working hard in this direction and we appreciate the validation that inline editing makes sense.
> (I believe in both their remote and open source approach)
GitHub is also remote.
GitHub is also remote.
The snow leopard reference makes me wish for the old days at Apple. The day I was forced to upgrade was a somber one.
Thanks for the feedback. Indeed we recognize the inconsistencies in the UI from search to other areas. Rather than overhaul entire GitLab with each new improvement, we typically apply the change to one area first, and incrementally bring it to other areas as we get more feedback. This also allows us to move quickly and make tweaks. Thanks!
In particular, we've introduced a number of real-time features for issues in the past few releases. We are working to bring these to merge requests soon to get consistency.
https://gitlab.com/gitlab-org/gitlab-ce/issues/29978 https://gitlab.com/gitlab-org/gitlab-ce/issues/31631 https://gitlab.com/gitlab-org/gitlab-ce/issues/31630
https://gitlab.com/gitlab-org/gitlab-ce/issues/29978 https://gitlab.com/gitlab-org/gitlab-ce/issues/31631 https://gitlab.com/gitlab-org/gitlab-ce/issues/31630
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).
As an EE customer I've been growing quite frustrated over regressions and their EE issues board being basically a black hole where my feature requests/bugs never get responses. There are so many quirks with Gitlab that I can't even think of them all off the top of my head anymore. I used to update it after a couple of days to the latest release (the Omnibus works amazingly) but now I don't even want to touch it when an update comes out for at least a month or two.
It's like they're just steamrolling ahead at 900mph without acknowledging any input from their paying customers.
Global/Group variables, I'm looking at you. Dealing with microservices and Gitlab has been incredibly unpleasant since I can't template out variables.
And come on, this is simple and absolutely horrendous to our UX. It was completely ignored until I sent in a support ticket regarding it. I do appreciate the prompt response once I sent in a ticket, but it just proved to me that it's completely pointless to submit tickets to the EE board. So what, am I better off sending my tickets to the gitlab.com board? What's the workflow here? I genuinely have no idea. Why isn't there an EE onboarding process and why don't I get support contacts/account managers as an Enterprise customer? In my experience the "Enterprise" issues are what is critical and trickle down into the community releases. That does not appear to be the case with Gitlab.
I know these are growing pains from growing so incredibly fast. I'm not asking for instantaneous results. I'm asking for communication. My ticket sat untouched for something like a month before I sent a support ticket in and it was then tagged as a feature request. Are you eating your own dog food, or am I eating your dog food and spitting out bones bone while paying for a quality meal?
https://gitlab.com/gitlab-org/gitlab-ee/issues/2124
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/... -- this guy is TEN months old and asking for a simple command line switch to modify the one, or one of, the few variables not available in the config.toml of a runner (which is bad enough in itself).
And no, telling me to run sed after the register is not even remotely the fix/response I was expecting. Not 6 months ago and not 10 months ago. I'm trying to improve your software. "Hey, your car doesn't shift into 2nd gear." "That's okay, if you kick the floor 2nd gear will fall into place." "Ok, well your 2nd gear still sucks and I don't want to drive this car anymore."
It's like they're just steamrolling ahead at 900mph without acknowledging any input from their paying customers.
Global/Group variables, I'm looking at you. Dealing with microservices and Gitlab has been incredibly unpleasant since I can't template out variables.
And come on, this is simple and absolutely horrendous to our UX. It was completely ignored until I sent in a support ticket regarding it. I do appreciate the prompt response once I sent in a ticket, but it just proved to me that it's completely pointless to submit tickets to the EE board. So what, am I better off sending my tickets to the gitlab.com board? What's the workflow here? I genuinely have no idea. Why isn't there an EE onboarding process and why don't I get support contacts/account managers as an Enterprise customer? In my experience the "Enterprise" issues are what is critical and trickle down into the community releases. That does not appear to be the case with Gitlab.
I know these are growing pains from growing so incredibly fast. I'm not asking for instantaneous results. I'm asking for communication. My ticket sat untouched for something like a month before I sent a support ticket in and it was then tagged as a feature request. Are you eating your own dog food, or am I eating your dog food and spitting out bones bone while paying for a quality meal?
https://gitlab.com/gitlab-org/gitlab-ee/issues/2124
https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/... -- this guy is TEN months old and asking for a simple command line switch to modify the one, or one of, the few variables not available in the config.toml of a runner (which is bad enough in itself).
And no, telling me to run sed after the register is not even remotely the fix/response I was expecting. Not 6 months ago and not 10 months ago. I'm trying to improve your software. "Hey, your car doesn't shift into 2nd gear." "That's okay, if you kick the floor 2nd gear will fall into place." "Ok, well your 2nd gear still sucks and I don't want to drive this car anymore."
We work out in the open on the EE issue tracker. But if you are a paying customer and have an urgent need it is better to contact support to get your issue prioritized.
I've asked our support team to comment if we can explain that better and to comment on the onboarding process.
I've asked our support team to comment if we can explain that better and to comment on the onboarding process.
[deleted]
[deleted]
[deleted]
Hi Swozey,
Adam from the support team here, we'd like to address each of your concerns individually to satisfy you (the customer) and also so we can improve our reporting process overall.
* As an EE customer I've been growing quite frustrated over regressions and their EE issues board being basically a black hole where my feature requests/bugs never get responses.
As there are no SLAs applied to the issues board often these issues are only picked up once a support ticket is lodged because in this scenario the service engineer will search for an existing issue to prevent duplicates then label the issue and assign a priority level.
We would recommend lodging an issue via the support web form [1] instead, with this we will reproduce then document the defect before escalating to the dev team. If you have already discovered an issue or have created a feature proposal, please follow up with the support team and link to your issue so we can assign the appropriate labels and developers to ensure the issue won't fall through the cracks. This process is outlined on our support page [2]. Also information about how we escalate issues can be found at https://about.gitlab.com/handbook/support/workflows/support_....
* I used to update it after a couple of days to the latest release (the Omnibus works amazingly) but now I don't even want to touch it when an update comes out for at least a month or two.
A recent feature added to GitLab is the ability to do canary deployments[3] which we are testing internally to improve our release process. We always aim to fix regressions quickly however at this point in time we do recommend waiting for a few patch releases before upgrading to the next minor/major release.
* It's like they're just steamrolling ahead at 900mph without acknowledging any input from their paying customers.
Customer feedback is one of most important decision making tools when deciding on the future direction of the application. We are often looking for advice from the community, a critical example of this is when we decided to remain on cloud infrastructure due to feedback from the community [4].
* Global/Group variables, I'm looking at you. Dealing with microservices and Gitlab has been incredibly unpleasant since I can't template out variables. And come on, this is simple and absolutely horrendous to our UX. It was completely ignored until I sent in a support ticket regarding it.
In this regard, lodging a support ticket is the correct course of action, the support team is here to either resolve or triage your issues so that they don't fall through the cracks. If you could please provide the URL of your support ticket then we will be able to review the mistakes that were made during this specific process and tend to them appropriately.
* I know these are growing pains from growing so incredibly fast. I'm not asking for instantaneous results. I'm asking for communication. My ticket sat untouched for something like a month before I sent a support ticket in and it was then tagged as a feature request.
The application is growing very fast but so is our team. We try our best not to set our SLAs below a level that we believe we are capable of handling. If a support ticket has breached we will be alerted, or if there is a lack of participation on your dev issue then please let us know so we can pick up the slack for you.
* https://gitlab.com/gitlab-org/gitlab-ee/issues/2124, https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/.... -- this guy is TEN months old and asking for a simple command line switch to modify the one, or one of, the few variables not available in the config.toml of a runner (which is bad enough in itself).
We admit that we dropped the ball on these issues. As per our guidelines[5] we should have pinged our product manager Mark P to get 2124 into a Production demo and pinged a CI product manager for issue #1539 (please note that this feature may exist[6], we will assign someone to investigate).
Hopefully this addresses most of your issues and please note that we are always improving our overall product, which includes support SLAs and issue resolution.
[1] https://support.gitlab.com [2] https://about.gitlab.com/support/ [3] https://about.gitlab.com/2017/04/22/gitlab-9-1-released/#can... [4] https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-t... [5] https://about.gitlab.com/handbook/product/#who-to-talk-to-fo... [6] https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma...
Adam from the support team here, we'd like to address each of your concerns individually to satisfy you (the customer) and also so we can improve our reporting process overall.
* As an EE customer I've been growing quite frustrated over regressions and their EE issues board being basically a black hole where my feature requests/bugs never get responses.
As there are no SLAs applied to the issues board often these issues are only picked up once a support ticket is lodged because in this scenario the service engineer will search for an existing issue to prevent duplicates then label the issue and assign a priority level.
We would recommend lodging an issue via the support web form [1] instead, with this we will reproduce then document the defect before escalating to the dev team. If you have already discovered an issue or have created a feature proposal, please follow up with the support team and link to your issue so we can assign the appropriate labels and developers to ensure the issue won't fall through the cracks. This process is outlined on our support page [2]. Also information about how we escalate issues can be found at https://about.gitlab.com/handbook/support/workflows/support_....
* I used to update it after a couple of days to the latest release (the Omnibus works amazingly) but now I don't even want to touch it when an update comes out for at least a month or two.
A recent feature added to GitLab is the ability to do canary deployments[3] which we are testing internally to improve our release process. We always aim to fix regressions quickly however at this point in time we do recommend waiting for a few patch releases before upgrading to the next minor/major release.
* It's like they're just steamrolling ahead at 900mph without acknowledging any input from their paying customers.
Customer feedback is one of most important decision making tools when deciding on the future direction of the application. We are often looking for advice from the community, a critical example of this is when we decided to remain on cloud infrastructure due to feedback from the community [4].
* Global/Group variables, I'm looking at you. Dealing with microservices and Gitlab has been incredibly unpleasant since I can't template out variables. And come on, this is simple and absolutely horrendous to our UX. It was completely ignored until I sent in a support ticket regarding it.
In this regard, lodging a support ticket is the correct course of action, the support team is here to either resolve or triage your issues so that they don't fall through the cracks. If you could please provide the URL of your support ticket then we will be able to review the mistakes that were made during this specific process and tend to them appropriately.
* I know these are growing pains from growing so incredibly fast. I'm not asking for instantaneous results. I'm asking for communication. My ticket sat untouched for something like a month before I sent a support ticket in and it was then tagged as a feature request.
The application is growing very fast but so is our team. We try our best not to set our SLAs below a level that we believe we are capable of handling. If a support ticket has breached we will be alerted, or if there is a lack of participation on your dev issue then please let us know so we can pick up the slack for you.
* https://gitlab.com/gitlab-org/gitlab-ee/issues/2124, https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/.... -- this guy is TEN months old and asking for a simple command line switch to modify the one, or one of, the few variables not available in the config.toml of a runner (which is bad enough in itself).
We admit that we dropped the ball on these issues. As per our guidelines[5] we should have pinged our product manager Mark P to get 2124 into a Production demo and pinged a CI product manager for issue #1539 (please note that this feature may exist[6], we will assign someone to investigate).
Hopefully this addresses most of your issues and please note that we are always improving our overall product, which includes support SLAs and issue resolution.
[1] https://support.gitlab.com [2] https://about.gitlab.com/support/ [3] https://about.gitlab.com/2017/04/22/gitlab-9-1-released/#can... [4] https://about.gitlab.com/2017/03/02/why-we-are-not-leaving-t... [5] https://about.gitlab.com/handbook/product/#who-to-talk-to-fo... [6] https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma...
Thank you for the feedback.
> There are couple of bugs open for months, even with existing merge request to fix
Are there specific bugs that you would really like to see fixed? Or specific flows you feel need love and attention sooner rather than later?
> There are couple of bugs open for months, even with existing merge request to fix
Are there specific bugs that you would really like to see fixed? Or specific flows you feel need love and attention sooner rather than later?
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.
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.
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.
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/CONTRIBU...
But if we can't make the behavior more intelligent we will probably have to add an option.
But if we can't make the behavior more intelligent we will probably have to add an option.
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.
It seems like it would be possible to have the best of both worlds by defaulting to checked for first PR from a branch, but defaulting to unchecked for subsequent PRs from the same branch (because if you didn't delete it last time, you probably don't want to delete it this time).
I think it's not bad to have it checked by default but a bit more intelligent it surely can be.
The biggest annoyance and source of confusion is when you make a merge request based on a protected branch. The checkbox is still there and checked but it won't actually delete the protected branch (well, that's good ;-)).
In that case the checkbox should just be not displayed at all.
In that case the checkbox should just be not displayed at all.
Or rather, displayed but disabled with a message explaining why it can't/won't be used.
Great suggestion, thanks!
Created https://gitlab.com/gitlab-org/gitlab-ce/issues/34248 to track.
Created https://gitlab.com/gitlab-org/gitlab-ce/issues/34248 to track.
We've had the same issue with "Squash commits", which are now turned on by default.
https://gitlab.com/gitlab-org/gitlab-ee/issues/2541#note_329...
https://gitlab.com/gitlab-org/gitlab-ee/issues/2541#note_329...
Thank you for the feedback. We're tracking how we can improve this functionality in this issue. Our design team is working hard on the merge request (the widget and the entire page) in general, and we are aiming to improve this part as part of that change.
https://gitlab.com/gitlab-org/gitlab-ce/issues/32885
https://gitlab.com/gitlab-org/gitlab-ce/issues/32885
IMO GitLab should seriously stop with the features and spend more time in making the UI look decent and aesthetically pleasing.
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.
Yeah, GitLab already "won" on the features. But it doesn't matter when they lose so much on the design.
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
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.
You can follow the main issue here: 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.
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.
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.
We have lots of ongoing UI work. You can always get an overview at https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...
If you have any specific issues, feel free to open an issue or share them here so I can open an issue for you.
If you have any specific issues, feel free to open an issue or share them here so I can open an issue for you.
I'm most impressed with https://docs.gitlab.com/ee/user/admin_area/monitoring/convde...
This is a game changer.
This is a game changer.
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.
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.
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.
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
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!
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!
>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/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.
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/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.
It's been a while since I've been on Gitlab, but you used to be able to add `[ci skip]` to a commit message and CI wouldn't run. It does litter your git history with CI information though.
https://docs.gitlab.com/ee/user/project/merge_requests/code_...
Is code climate a free product or paid only?
Is code climate a free product or paid only?
Code quality is based on the open source code of code climate but it is a feature available only in enterprise edition.
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?
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).
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
Thanks for GitLab and the helpful link. It's also nice to see you're keeping https://about.gitlab.com/direction/ up to date. Lots of nice stuff in there, including ops features.
You're welcome. And thanks for linking /direction. We auto generate it via our API so it is always up to date.
It seems that you brought the sticky/fixed header back. Why? :(
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
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.