@m_frankiewicz @paulobarros I am writing to you regarding the current situation we're facing due to this bug. We need this to work, otherwise our pipelines are broken and this makes GitLab as a platform unusable for us at the moment in its current configuration. I hope you can prioritize this. Are there any updates and next steps?

Feel free to reach out to me if you need more context or if we can test a workaround.

https://gitlab.my.salesforce.com/0014M00001kI5MG PremiumBlocker

Thanks for the update Manuel. Sounds like a good approach for your backlog!

Hi @rutshah,

Is there any update on the timeline for this issue?

As you can see multiple customers are affected...

As currently described, the limitation breaks expected CI/CD logic workflows when diffs exceed certain thresholds.

Could we please consider increasing this issue’s priority? It’s risking product consistency product conformity.

@marknuzzo I wonder why this is being pushed form candidate to candidate label. Already GL18 now... As you can see other super large customers are also affected...

Hi @phikai,
I'm reaching out from a team using GitLab Premium, and we’d really love to see this feature implemented. It would make a big difference in our daily work — being able to quickly spot other open MRs that touch the same files would help us avoid conflicts and streamline collaboration across teams.

Do you have any sense of when this might get picked up? We'd really appreciate any insights on the timeline or roadmap status.

Thanks a lot for all the great work you and the team are doing!

https://gitlab.my.salesforce.com/0014M00001kI5MG

Hi @paulobarros,

Do you have any update on the timeline for this? It’s currently blocking a major part of our project development, specifically user onboarding, so we’d really appreciate any insight on expected availability. Also curious if there are still significant technical or organisational barriers to overcome?

Thanks a lot in advance!
Maximilian

Customer-ID: https://gitlab.my.salesforce.com/0014M00001kI5MG

Hi @phikai, a change in review process for example? It is not uncommon that this might change, due to changes in the working-guideline.

Hi @lalabi, hi @phikai,

we're a Premium customer and this issue is causing serious trouble for us — when a branch rule is deleted, its approval rules suddenly apply to all branches. This breaks our workflows and could significant damage to product and workflows.

We’ve opened a Salesforce case here: https://gitlab.my.salesforce.com/0014M00001kI5MG\ Would really appreciate it if this could be looked at with urgency. Thanks!

Hi @paulobarros, unfortunately this feature didn't make it into 17.10. How optimistic are you about 17.11?

Can't wait for this feature. It is currently blocking a mayor transformation on a big project right ahead. https://gitlab.my.salesforce.com/0014M00001kI5MG

Hi @avonbertoldi, thanks for the insights.

I wonder why this fix cannot be applied to provide a first rather quick solution to the issue: #38587 (comment 2369732201)

FROM registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v17.8.3-servercore21H2
ENV GIT_CONFIG_NOSYSTEM=

Hi @avonbertoldi, hi @ajwalker, as already commented here, his issue has a significant impact on Windows-based builds.

Which of the two issues is prioritised?

What I don’t understand is why this bug, reported in the 17.8 release, was not addressed in the 17.9 release. Could you clarify what the technical complexity is in fixing this?

https://gitlab.my.salesforce.com/0014M00001kI5MG

Hi @avonbertoldi, hi @ajwalker,

wasn't able to find this issue directly and support in 609819.

This issue has a significant impact on Windows-based builds. This leads to build failures whenever paths exceed the 260-character limit, which is a critical blocker for many projects.

We had no choice but to roll back our entire Windows runner fleet, resulting in a significant loss of development time and disruption to our workflows. This regression is unacceptable — Windows long path support is essential, and breaking it without a fix in place has caused major setbacks.

Can we get an urgent update on a resolution or workaround? Restoring system-level Git configurations must be prioritised to prevent further damage.

https://gitlab.my.salesforce.com/0014M00001kI5MG

This feature is critical for our organization as it impacts our ability to manage permissions effectively and maintain security compliance.

The number of people requesting this and creating duplicate issues should be more than enough reasons to give this weight, right?

Could you please provide an update on the current status and any estimated timelines for its implementation? https://gitlab.my.salesforce.com/0014M00001kI5MG

One more question: We have been deleting pipelines in this matter:

    def get_pipelines_in_range(
        self, project_id: int, before: str, max_pipelines: int = 100
    ) -> list:  # type: ignore[type-arg]
        
        # GET /projects/:id/pipelines
        max_pages = int(max_pipelines / 20)
        pipelines = self.gl.get_request_with_pagination(
            f"projects/{project_id}/pipelines",
            {"updated_before": before, "order_by": "updated_at", "sort": "asc"},
            max_page=max_pages,
        )
        logger.info("Pipelines in range: " + str(len(pipelines)))
        return pipelines  # type: ignore[no-any-return]


    def delete_pipeline(self, project_id: int, pipeline: dict) -> requests.Response:
        # DELETE /projects/:id/pipelines/:pipeline_id
        responce = self.gl.delete_request(f"projects/{project_id}/pipelines", pipeline["id"])
# Some filtering
        return responce

    def clean_pipelines(self, project_id: int, before: str) -> None:
        """Clean the pipelines in a given range.

        Args:
            project_id: Id of the project.
            before: ISO 8601 string.
        """
        # Get 100 pipelines and delete them
        pipelines = [0]
        while pipelines:
            pipelines = self.get_pipelines_in_range(project_id, before, max_pipelines=100)
            logger.info(f"Successfully fetched {len(pipelines)} pipelines")
            if not pipelines:
                break
            threads = [Thread(target=self.delete_pipeline, args=(project_id, pipeline)) for pipeline in pipelines]  # type: ignore[index]
            for thread in threads:
                thread.start()
            for thread in threads:
                thread.join()

We have a lot of bridge and downstream-pipelines. Could I be that they are not deleted properly by the new feature?

Hi @hfyngvason, your assumption is right. Looking forward for your next steps in resolving this (major) issue...

BR Maximilian

Hi @dzalbo, how positive are you about the current candidate label. Can't wait to get this one off my list...

Hi @rutshah,

can't wait to get this one off the list. How positive are you about getting this in the product by 17.11?

BR Maximilian

I've been looking through gitlab-foss#44798 (closed) and linked issues and that's how I found this, most recent, one. I was not able to find any possibility for me as admin to provide data on when a user confirmed terms & conditions (and which one) as depicted in this original requirement:

The accept is logged in the database with at least the timestamp. (To capture the audit requirement.)

gitlab-foss#44798 (closed)

Has this ever been implemented?

@jeremy_ @jramsay @reprazent

@mbobin thanks for the ultra-fast reply. I already have a script to do this on hand, however while going through the process I thought of new projects, which won't have the setting unless I run this script on a regular basis...

Thanks for the good work @mbobin @drew. Can't wait for the final release. I am already testing on GL 17.8.1 on our on prem instance. Big pipeline templating causes a lot of junk being collected in DB can't wait to run the prune to see the results.

One question that I still have: Will this be instance-wide on prem setting in the admin CI/CD section?