> "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.
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
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-...
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.)
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.
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...
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.
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.
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
@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