[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Git commit content
From:       Helio Chissini de Castro <helio () kde ! org>
Date:       2022-08-29 6:24:16
Message-ID: CAKPiqoFFGPxmtLSz=-T09y6k2u1N5deALcedNQF5quT_1BPBOg () mail ! gmail ! com
[Download RAW message or body]

Honest question

Since these files are generated, and create huge hurdles to commit, was not
make sense to generate this on build time and avoid such huge commits ?

Or we have a technical block that maybe we can help to solve ?


[]'s

On Sun, Aug 28, 2022 at 1:17 PM Ben Cooksley <bcooksley@kde.org> wrote:

> Hi all,
>
> Over the past couple of months we have had several incidents where people
> have needed/attempted to push large text files into KDE Git repositories.
>
> While this does not seem immediately problematic, it is something that
> unfortunately the email sending components of our Git hooks are unable to
> handle (likely due to them embedding commit diffs into the body of emails).
>
> This results in them consuming an entire CPU core of the server until
> Gitlab times out on them and kills them (failing the push/merge in the
> process).
>
> For the most part these have been programmatically generated data sources,
> making the diffs of little use.
>
> Where possible it is recommended not to commit these sort of artifacts to
> KDE Git repositories, but where it is not avoidable please ensure that:
> a) The data is not all on a single line (JSON pretty print where possible);
> b) That the file has been flagged as binary data using .gitattributes
>
> This should assist the email generating components of the hooks in more
> easily handling the content.
>
> Thanks,
> Ben
>

[Attachment #3 (text/html)]

<div dir="ltr"><div class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large">Honest  question</div><div \
class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large"><br></div><div \
class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">Since \
these files are generated, and create huge hurdles to commit, was not make sense to \
generate this on build time and avoid such huge commits ?</div><div \
class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large"><br></div><div \
class="gmail_default" style="font-family:verdana,sans-serif;font-size:large">Or we \
have a technical block that maybe we can help to solve ?</div><div \
class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large"><br></div><div \
class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large"><br></div><div \
class="gmail_default" \
style="font-family:verdana,sans-serif;font-size:large">[]&#39;s</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 28, 2022 at 1:17 PM \
Ben Cooksley &lt;<a href="mailto:bcooksley@kde.org">bcooksley@kde.org</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi \
all,<div><br></div><div>Over the past couple of months we have had several incidents \
where people have needed/attempted to push large text files into KDE Git \
repositories.</div><div><br></div><div>While this does not seem immediately \
problematic, it is something that unfortunately the email sending components of our \
Git hooks are unable to handle (likely due to them embedding commit diffs into the \
body of emails).</div><div><br></div><div>This results in them consuming an entire \
CPU core of the server until Gitlab times out on them and kills them (failing the \
push/merge in the process).</div><div><br></div><div>For the most part these have \
been programmatically  generated data sources, making the diffs of little use.  \
</div><div><br></div><div>Where possible it is recommended not to commit these sort \
of artifacts to KDE Git repositories, but where it is not avoidable please ensure \
that:</div><div>a) The data is not all on a single line (JSON pretty print where \
possible);</div><div>b) That the file has been flagged as binary data using \
.gitattributes</div><div><br></div><div>This should assist the email generating \
components of the hooks in more easily handling the content.  \
</div><div><br></div><div>Thanks,</div><div>Ben</div></div> </blockquote></div>



[prev in list] [next in list] [prev in thread] [next in thread]