Oh man, oh man, global hooks! Thank you!
The other features are awesome, but this is the one that will get us to upgrade right now! We use dozens of repositories, and it's been a pain to manually configure and update hooks.
GitLab 8.15 Released
61–70 of 117 posts
Re: GitLab 8.15 Released
#62Earlier quoted context omitted.
Pardon me here, but I don't understand what you mean by "the docker image most people use is unofficial." I was under the impression that everyone used the fully featured official docker image ( https://hub.docker.com/r/gitlab/gitlab-ee/ ). We've been using this for over a year without issues now. Is there a reason you need the unofficial version? Does it do something different?
IIRC because last time I checked it had no comments/community around it and was until recently out of date.
The image Cidan referred to was last pushed 5 hours ago when we released 8.15 and should always be up to date. For more information about our official docker images see https://docs.gitlab.com/omnibus/docker/README.html
I've added a section to say that these images are officially supported with https://gitlab.com/gitlab-org/omnibus-gitlab/commit/26501d91...
If you experience problems with them please feel free to file an issue under https://gitlab.com/gitlab-org/omnibus-gitlab/issues (more than 1500 have been closed there already).
I suspect that many of the upgrade problems you experienced can be solved by using an official image.
I agree that the demo video we show is limited to a specific Kubernetes installation (OpenShift self hosted). In 2017 we plan to make sure everyone can use it, for details see https://gitlab.com/gitlab-org/gitlab-ce/issues/25986
Re: GitLab 8.15 Released
#63Earlier quoted context omitted.
Great, I'm glad it worked for you. It didn't work for me and other people, as per the issues linked. When it doesn't work, there's no clearly defined debug path, and very little response.
Respectfully, it seems like you are using the wrong Docker image, and that's the source of your troubles. Others have commented similarly, and I think that you are too easily dismissing them.
I think you're right Aaron.
The Sameer docker image used to be the only way to run GitLab with Docker but we don't recommend it and it is no longer listed on our installation page https://about.gitlab.com/installation/ to prevent confusion.
Also see my answer in https://news.ycombinator.com/item?id=13243443
Re: GitLab 8.15 Released
#64Earlier quoted context omitted.
Aha! I was looking for this recently. Doesn't appear to be on https://about.gitlab.com/installation/ , which is where I stopped my search for it.
It's very new and still maturing. Pull requests and improvements welcome!
Thanks for making it Greg. I added it to the community installation methods section of https://about.gitlab.com/installation/ with https://gitlab.com/gitlab-com/www-gitlab-com/commit/c4ea6aa9...
Re: GitLab 8.15 Released
#65This is nice and all but what about page load times? It can have all the bells and whistles but if you have to wait a minute for just one page to load, it's unusable.
We've spent quite a bit of time this year improving performance, GitLab.com is still slower than it should be but it's a lot better now than it was in January. Self-hosted instances that meet the recommended specs are already fairly performant, though we're always working to improve things regardless. As mentioned in the blog post, this release we decreased page size a lot (from 1800kb to 718kb for a given Merge Requ…
It's a bit better but still extremely slow (didn't try on premise). We're still using it instead of github because of the CI though
Re: GitLab 8.15 Released
#66I love gitlab! We just deployed our review app deployment to Kubernetes (create a new subdomain in route53, create a new namespace in k8s, create all kubernetes manifests in that namespace, create ingress manifest, boom!). Here's some thing I wish for gitlab: 1. On merge, run "stop_review" so that we don't end up with a lot of old review apps. 2. I wish you could take over https://github.com/sameersbn/docker-gitlab o…
Glad to hear you love GitLab and are using the review apps https://about.gitlab.com/features/review-apps/
Thanks for the wish list!
1. Automatically stopping the review on merge makes a lot of sense. The issue for that is in https://gitlab.com/gitlab-org/gitlab-ce/issues/22191 and it got added to 8.13 if I'm not mistaken https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6669
2. As you know we already have official docker images with https://docs.gitlab.com/omnibus/docker/ so we won't take over Sameer his work. If you want to have separate containers for the datastores (totally a good idea) I recommend you use the Helm Chart https://github.com/kubernetes/charts/tree/master/stable/gitl... It has separate containers for Redis and PostgreSQL https://github.com/kubernetes/charts/blob/master/stable/gitl...
Re: GitLab 8.15 Released
#67Plan meets final execution, love it guys and gals, great work yet again, we upgraded today without a hitch, within 30 minutes I had devs making positive comments in chat about the upgrade. Thank you again for all your hard work and the passion that drives that.
Re: GitLab 8.15 Released
#68Earlier quoted context omitted.
Thanks for the honest feedback, it's genuinely useful for improving the product. Out of curiosity, why use the Docker image over our Omnibus package? Omnibus is generally what we recommend, but if that's not good enough we'd love to know how it can be improved.
Omnibus makes a ton of assumptions about how many things you want bundled, as well as the monolithic configuration is daunting. I'd suggest breaking up into smaller containers for each service. No matter what container medium you choose, the philosophy of omnibus isn't something you want to 'containerize' as it is.
We run gitlab and the full config is 57 lines. A little more than half of those are comments or blank lines. This includes email and oauth. I would suggest not unbundling.
Re: GitLab 8.15 Released
#69As a paying gitlab ee customer, we love to use gitlab. I just have one gripe with review apps. We would really like you to open it up with an API. Allowing us to create the infrastructure outside of gitlab-ci and setting the reviewapp url/domain etc using the API would be extremely valueable for us, as we are stepping off of the gitlab-ci, but would very much like the UI interface upgrades review apps provides. We ar…
If you have specific functionality that is now only in the interface in an API we'd be glad to have a look. But it sounds like you want to replace functionality in .gitlab-ci.yml with an API, this would be hard.
Instead we would gladly word with you to make GitLab CI better so you can keep using it.
1. Single pipeline => I understand using a monorepo. But I don't understand yet why you need multiple pipelines. Does the pipeline work different depending on what file is updated?
2. Do you mean cross project pipelines? https://gitlab.com/gitlab-org/gitlab-ee/issues/933
3. Do you mean setting criteria for build skipping in .gitlab-ci.yml ? What would be an example criteria?
Since you are a paying customer feel free to work with our support team to have the features you need prioritized. We want everyone to be able to use GitLab CI.
Re: GitLab 8.15 Released
#70Earlier quoted context omitted.
I also work at GitLab on a non-infra team. Here is Sid's explanation: https://gitlab.com/gitlab-com/infrastructure/issues/727#note... I, personally, was apprehensive of going to bare metal for most of the reasons that Sid lists in the above message, and I think that making the app just _better_ is where we should focus before we try and run to pure hardware to solve the problem.
Thanks for the link. I understand the rationale, it's definitely not a simple decision, but if these improvements can be made at the application layer then by all means go for it.
Yes, we're going for the application layer improvements. For our work there please see https://gitlab.com/gitlab-org/gitaly