From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, Ezekiel Newren <ezekielnewren@gmail.com>,
"brian m. carlson" <sandals@crustytoothpaste.net>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 2/6] ci: check formatting of our Rust code
Date: Wed, 29 Oct 2025 22:19:11 +0100 [thread overview]
Message-ID: <aQKEz5bnPHuCSjlR@szeder.dev> (raw)
In-Reply-To: <aOdIRnB-SGQwj935@pks.im>
On Thu, Oct 09, 2025 at 07:29:42AM +0200, Patrick Steinhardt wrote:
> On Wed, Oct 08, 2025 at 10:55:43PM +0200, SZEDER Gábor wrote:
> > On Tue, Oct 07, 2025 at 02:36:30PM +0200, Patrick Steinhardt wrote:
> > > diff --git a/ci/run-rust-checks.sh b/ci/run-rust-checks.sh
> > > new file mode 100755
> > > index 0000000000..082eb52f11
> > > --- /dev/null
> > > +++ b/ci/run-rust-checks.sh
> > > @@ -0,0 +1,12 @@
> > > +#!/bin/sh
> > > +
> > > +. ${0%/*}/lib.sh
> > > +
> > > +set +x
> > > +
> > > +if ! group "Check Rust formatting" cargo fmt --all --check
> > > +then
> > > + RET=1
> > > +fi
> > > +
> > > +exit $RET
> >
> > Our ci/*.sh scripts usually rely on 'set -e' to catch failed commands.
> > Either this script should follow that convention as well, or the
> > commit message should justify the deviation from convention.
>
> Ah, good point. The reason is that subsequent commits add more checks,
> and I want to make sure that they all run even if previous checks
> failed. It's otherwise annoying to fix a first set of errors surfaced by
> the CI only to then notice that later checks also fail.
Well, OTOH, it is annoying when the error messages from a failed CI
run are not at the bottom of the logs.
next prev parent reply other threads:[~2025-10-29 21:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-07 12:36 [PATCH 0/6] ci: improvements to our Rust infrastructure Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 1/6] ci: deduplicate calls to `apt-get update` Patrick Steinhardt
2025-10-07 12:54 ` Karthik Nayak
2025-10-14 20:56 ` Justin Tobler
2025-10-07 12:36 ` [PATCH 2/6] ci: check formatting of our Rust code Patrick Steinhardt
2025-10-07 13:04 ` Karthik Nayak
2025-10-07 13:50 ` Patrick Steinhardt
2025-10-07 17:13 ` Eric Sunshine
2025-10-07 17:38 ` Junio C Hamano
2025-10-07 18:03 ` Eric Sunshine
2025-10-07 22:42 ` brian m. carlson
2025-10-07 22:58 ` Chris Torek
2025-10-08 4:46 ` Patrick Steinhardt
2025-10-08 15:34 ` Junio C Hamano
2025-10-09 5:29 ` Patrick Steinhardt
2025-10-29 22:54 ` SZEDER Gábor
2025-10-07 22:07 ` brian m. carlson
2025-10-08 20:55 ` SZEDER Gábor
2025-10-09 5:29 ` Patrick Steinhardt
2025-10-29 21:19 ` SZEDER Gábor [this message]
2025-10-07 12:36 ` [PATCH 3/6] rust/varint: add safety comments Patrick Steinhardt
2025-10-08 0:29 ` brian m. carlson
2025-10-08 4:46 ` Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 4/6] ci: check for common Rust mistakes via Clippy Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 5/6] ci: verify minimum supported Rust version Patrick Steinhardt
2025-10-07 12:36 ` [PATCH 6/6] rust: support for Windows Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 0/6] ci: improvements to our Rust infrastructure Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 1/6] ci: deduplicate calls to `apt-get update` Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 2/6] ci: check formatting of our Rust code Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 3/6] rust/varint: add safety comments Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 4/6] ci: check for common Rust mistakes via Clippy Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 5/6] ci: verify minimum supported Rust version Patrick Steinhardt
2025-10-15 6:04 ` [PATCH v3 6/6] rust: support for Windows Patrick Steinhardt
2025-11-20 19:45 ` Ezekiel Newren
2025-11-21 8:18 ` Johannes Schindelin
2025-11-21 21:39 ` Junio C Hamano
2025-10-15 15:21 ` [PATCH v3 0/6] ci: improvements to our Rust infrastructure Junio C Hamano
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=aQKEz5bnPHuCSjlR@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=ezekielnewren@gmail.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
--cc=sandals@crustytoothpaste.net \
/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.