joshlambert

> "Advanced" search is completely useless as you can't really search for code.

@deng - thanks for the feedback. I am on the Product team for our Search service, code search is not where we would like it to be.

We are in-progress on swapping out the backend for code search from Elastic to Zoekt, which should provide a much more reliable and complete set of search results. You can read more about our plans for fixing code search here: https://about.gitlab.com/direction/global-search/code-search...

This is the key deliverable for the team, and we are making efficient progress. If you have feedback on our plans, we would love to hear it. The epic is here: https://gitlab.com/groups/gitlab-org/-/epics/9404

@cmckn - PM @ GitLab here - sorry to hear you had a poor experience with running our GitLab chart on k8s. We've been trying really hard to make this easier, but there is still some room to go especially on the documentation front: https://gitlab.com/groups/gitlab-org/-/epics/5273.

I'd love to hear what you had trouble with, so we can continue to improve. If you'd like, can also open an issue here: https://gitlab.com/gitlab-org/charts/gitlab/-/issues

Hi, GitLab product manager here. I'm sorry that we haven't provided a good experience. We try really hard to make sure GitLab deployments "just work", and clearly it does not for either of you.

Both Puma and Unicorn should be killed after they exceed a certain size to avoid this situation from happening. It's possible either this is not working in some situations/configurations, or there is a leak elsewhere although this is the first time I have heard reports of this.

What configuration is being changed from the defaults? Alternatively if you could open an issue with any additional detail we will try to figure out what is happening and fix it: https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues

Thanks for the feedback entha_saava. GitLab.com is indeed slower than GitHub.com today, and we need to provide a better experience for our users.

Improving frontend performance is a key focus area for us, and while we started this specific initiative recently, we have started prefetching data while our Vue app is loading (https://gitlab.com/gitlab-org/gitlab/-/issues/220511) and will be splitting out page specific assets out of the main bundle (https://gitlab.com/groups/gitlab-org/-/epics/3694).

We have quite a few other initiatives in flight, and will continue to provide updates on progress which you can see here: https://gitlab.com/groups/gitlab-org/-/epics/3273#note_37091...

Please read through the upgrade notes for 13.0 as there are some important changes like PG11 being a minimum requirement.

As for the actual upgrade, you should be able to follow the standard process outlined here since you are persisting your data outside the container: https://docs.gitlab.com/omnibus/docker/#update

The breakdown is probably close to the percentage of paying versus open source customers that we have.

We are working to better educate our users on the value that our paid version can offer, but it is very important for us to be good stewards of the open source community that has grown around the project. You can read more about our pricing strategy and stewardship here: https://about.gitlab.com/company/stewardship/#what-features-...

On the revenue side, Sid publicly shared an update recently: https://twitter.com/sytses/status/1156571842653478913?s=21

Hi, we do believe in the single application offering the best long term user experience and outcomes, but do understand that all of our features may not work for everyone. This is happens for a variety of reasons (completeness, migrations, specific project requirements, etc.)

Because of this, we do offer our API and the ability for our community to contribute integrations directly to the codebase. We have a pretty rich set today, you can see at: https://docs.gitlab.com/ee/user/project/integrations/project...

We're also working to further improve our integration options, with a dedicated team: https://about.gitlab.com/direction/ecosystem/. This team will be responsible for our broader API, an upcoming SDK, as well as continuing to improve our existing integrations like JIRA and Jenkins. This team is just getting under way, but I wanted note our investments here.

> Github API integration is stellar, API token permissions can be configured granularly, Github apps marketplace is awesome way to start using third party services.

PAT granularity has indeed been a pain point, and we should be solving this soon by offering the ability to restrict them by groups/projects: https://gitlab.com/groups/gitlab-org/-/epics/182

Hi - I'm sorry for the experience you had. I'm the PM for our Runner team, and we're focusing our next milestone purely on fixing some high priority outstanding bugs, that have been open for longer than they should have.

Is this the issue you are referring to about the cache issues? https://gitlab.com/gitlab-org/gitlab/issues/21409 If so, it seems like it got lost in our triage system, I've set appropriate labels so now it should get the appropriate visibility.

Hi - thanks for the feedback, we aren't where we want to be with performance. We are working hard to improve responsiveness and memory consumption, and have a recently started a team focused on just these aspects to accelerate the improvements. You can read more about the rationale here, including stories like yours: https://about.gitlab.com/2019/09/13/why-we-created-the-gitla...

One of the major projects the team is working on, is to switch from unicorn to puma: https://docs.gitlab.com/omnibus/settings/puma.html

We are also continuing our broader effort at improving performance each release, for example in 12.2 we had 58 MR's focused on performance improvements: https://about.gitlab.com/2019/08/22/gitlab-12-2-released/#pe...

Hopefully you will start to feel the impact of these investments soon.

Hi - just wanted to confirm that this issue has been addressed and will be included in our 12.4 runner release.

MR: https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1...

Hi - we've been discussing how to better anchor these on quantitative data, rather than the subjective opinion of GitLab PM's.

You can see some of the discussion here (https://gitlab.com/gitlab-com/Product/issues/323) which continued to some degree here (https://gitlab.com/gitlab-com/Product/issues/386).

If you have feedback on some other metrics to use, please contribute! I don't think we've landed on the right formula just yet. But directionally, we'd like these to be based on user outcomes rather than our own opinion.

Thanks for the additional information. The `git_data_dir` and gitaly configuration changes are indeed why we've started requiring moving to the last minor version first. The 10.x to 11.x upgrade was the first major upgrade with these checks, but it doesn't look like we captured all the possible scenarios. (We did prevent a few upgrade failures though, based on customer feedback.)

It is very important for the team to ensure upgrades are smooth. Right around 50% of our installations are running a version at most 3 months old, and we want to continue to improve that number so everyone can take advantage of the latest fixes, features, and security updates.

The team has opened another issue to explore ways to make it more apparent which version should be upgraded to: https://gitlab.com/gitlab-org/distribution/team-tasks/issues....

Hi, I'm a PM for our linux packages. I'd love to learn more about the cryptic issues and vague errors mention.

We've put a lot of effort towards making the upgrades as painless as possible, with few surprises. One way we've achieved this is by requiring users to update to the last minor version, before making the jump to the next major version, as you note. The reason for doing this, is that we add a lot of validation to that last minor package which checks for any deprecated features/configuration.

This way if you try to upgrade with a configuration that would result in GitLab no longer functioning, we abort the upgrade and tell you exactly why, leaving you with a functional instance in the interim.

Thanks, and please keep up the feedback. =)

Merge request to link to our definition of PNPS: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/.... Should be merged momentarily.

Thank you for the feedback. We aren't happy with performance and we are working hard to improve it. We have two major projects under way, switching to Puma (https://docs.gitlab.com/omnibus/settings/puma.html) as well as reducing the overall memory consumption of GitLab (https://about.gitlab.com/handbook/engineering/development/en...).

You can follow along on some of the progress we are making in each release post in the "Performance Improvements" section. For 12.2 you can see we had 58 MR's related to performance: https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=....

On the UX front, two efforts under way are establishing experience baselines (https://about.gitlab.com/handbook/engineering/ux/experience-...) as well as a common design system (https://about.gitlab.com/handbook/engineering/ux/pajamas-des...). Hopefully these efforts allow us to look at our UX holistically, and to focus on making high quality components that are used throughout the product.

Again thanks for the feedback, and hopefully we will have some more concrete improvements here soon.

We have established teams for each of our DevOps stages: https://about.gitlab.com/stages-devops-lifecycle/

Package encompasses both the Container Registry, as well as other repository types like Maven, NPM, etc.

I'm sorry this has taken so long, but we are working on some foundational API's to manage and list images right now: https://gitlab.com/gitlab-org/gitlab-ce/issues/55978. I've also added your feedback on sorting, thank you!

We are also setting up a team to focus on just packaging related features within GitLab, like the Registry, which should improve our velocity in this area.

slap_shot one of our major goals is to provide a solution that startups and small companies can utilize to start putting their data to work.

It shouldn't take weeks of effort, a data engineer, multiple proprietary solutions, and tens of thousands of dollars to answer key questions like CAC or the efficiency of a given marketing campaign.

We're hoping to lower the barrier to entry in both cost and effort, by providing an open source pre-packaged solution.

Thanks for watching mfer! Kaniko certainly doesn't address all of the challenges with building containers securely, but I think it's the best solution available _today_ that supports the common Dockerfile workflow.

There are a number of other promising tools like img, but aren't readily usable yet because of a dependency on some upstream PR's.

At GitLab, we're trying to think of ways to help developers understand the challenges, as well as provide easy to adopt solutions as these tools become available. Would love your thoughts and feedback: https://gitlab.com/gitlab-org/gitlab-ce/issues/48913

We've had Mattermost integrated for quite some time, it predates the gitter acquisition. It's in use by around 5% of our installations and has a passionate userbase.

samm we are indeed making all components that are not core gitlab services optional. You will be able to turn them off with a simple `prometheus.enabled=false`.

Thanks for giving the charts a try in alpha/beta, please pass along any feedback. We'd love to get it!

jancsika, totally understand the forking workflow is not ideal right now. Thanks for sharing your use case and using GitLab.

We are tracking more formal support for this here: https://gitlab.com/gitlab-org/gitlab-ce/issues/23902

It's a popular issue, but there are some tricky implementation details to work out.

If it is a forked project, CI should run in their own project I believe. It should not run on your Runners.

Quick note, the existing Let's Encrypt integration does not support Pages. We are working on it, but it's worth noting Pages has multiple modes it can run in.

One is by setting up wildcard domains at the server level, like we have on GitLab.com with gitlab.io. We have an issue open for this, but the primary challenge is that Let's Encrypt requires DNS-01 validation for wildcard certificates, with a new challenge each renewal. That is difficult to automate through our Omnibus package. The issue tracking this work is here: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3342

The other method allows users bring their own "custom domains": https://docs.gitlab.com/ee/administration/pages/#custom-doma...

This is easier to manage, as we can do HTTP or SNI validation for each domain without hitting LE's rate limits. We are working on this now here: https://gitlab.com/gitlab-org/gitlab-ce/issues/28996

Thanks for the report @theptip.

Did you happen to open an issue? It would be great to ensure this one is being tracked appropriately.

@jancsika you could implement a whitelist using this feature, by having jobs only run for specific usernames.

Keep in mind though that these variables can be overridden, so it probably shouldn't be used for security reasons: https://docs.gitlab.com/ce/ci/variables/README.html#priority...

To give a more detailed example on the nightly build, you would create a pipeline schedule that ran once per day and specified a variable: https://docs.gitlab.com/ee/user/project/pipelines/schedules....

Then you'd only trigger the nightly build job when this variable was present, using the `only` flag with the variable you defined for the job: https://docs.gitlab.com/ee/user/project/pipelines/schedules....

In my experience the GitLab Runner on k8s should utilized the cache. Are you using Docker-in-Docker by chance? By default, I don't think it can cache data between jobs.

I agree, that would be awesome!

While it's not a single button, GitLab is getting closer to that goal with the addition of our cluster integration feature: https://docs.gitlab.com/ee/user/project/clusters/#adding-and...

If you create a trial account on GCP, you can then use GitLab to make a new GKE cluster and it will be automatically linked. You can then click a single button to deploy the Helm Tiller, a GitLab Runner, and then run your CI/CD jobs on your brand new cluster!

The GCP trial is pretty nice, you get $300 in credits and you won't be automatically billed at the end: https://cloud.google.com/free/

Thanks, glad you are finding it helpful!

We have a lot of improvements coming as well: https://about.gitlab.com/direction/#ci--cd