All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,  Karthik Nayak <karthik.188@gmail.com>
Subject: Re: [PATCH] gitlab-ci: fix "check" jobs with large merge requests
Date: Fri, 16 Oct 2026 10:15:57 -0700	[thread overview]
Message-ID: <xmqqtsmlftwy.fsf@gitster.g> (raw)
In-Reply-To: <20261016-pks-ci-optional-whitespace-job-v1-1-f5693fbae1a5@pks.im> (Patrick Steinhardt's message of "Fri, 16 Oct 2026 16:48:20 +0200")

Patrick Steinhardt <ps@pks.im> writes:

> The "check-whitespace" and "check-style" jobs verify that the changes
> proposed by a merge request don't introduce whitespace errors or style
> violations. To do so, both of them compare against the base commit of
> the merge request.
>
> But both GitHub and GitLab use shallow clones to set up the repository
> in CI jobs by default. So if the base commit to compare against is
> beyond the shallow boundary then these checks will fail. To avoid that
> error we thus configure GitHub CI to disable shallow clones via
> `fetch-depth: 0`. But we don't do the equivalent for GitLab, so we see
> such errors whenever we have a merge request with more than 50 commits,
> which is the configured shallowness for gitlab-org/git.
>
> Fix these issues by setting GIT_DEPTH to 0 for both jobs so that we
> always fetch the full history.

Hmph, that is annoying.  In theory, you only need to fetch from the
base that the patch series is designed to apply, but I guess that is
not a choice offered.

How much help are we really getting from these two jobs, by the way?
If we disabled them, would we suddenly start seeing uncontrollable
amount of crap patches full of whitespace breakages and style
violations?

Will queue, thanks.

>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> Hi,
>
> one more day, one more CI annoyance. The "check-whitespace" job is
> somewhat broken for us in case we have MRs that have more than 50
> commits. And while that's not something that happens for patch series
> that we send upstream, it does happen for some of our internal
> development branches.
>
> See [1] for a pipeline run with these changes.
>
> Thanks!
>
> Patrick
>
> [1]: https://gitlab.com/gitlab-org/git/-/merge_requests/703
> ---
>  .gitlab-ci.yml | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 3f24835500..62737279d2 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -256,6 +256,8 @@ check-whitespace:
>    image: ubuntu:latest
>    stage: analyze
>    needs: [ ]
> +  variables:
> +    GIT_DEPTH: 0
>    before_script:
>      - ./ci/install-dependencies.sh
>    # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged
> @@ -276,6 +278,7 @@ check-style:
>    variables:
>      CC: clang
>      jobname: ClangFormat
> +    GIT_DEPTH: 0
>    before_script:
>      - ./ci/install-dependencies.sh
>    # Since $CI_MERGE_REQUEST_TARGET_BRANCH_SHA is only defined for merged
>
> ---
> base-commit: f57c9a73884400380bddd172acc88b569834f909
> change-id: 20261016-pks-ci-optional-whitespace-job-ff1effc3fec7

      reply	other threads:[~2026-10-16 17:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16 14:48 [PATCH] gitlab-ci: fix "check" jobs with large merge requests Patrick Steinhardt
2026-10-16 17:15 ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqtsmlftwy.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.