From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, Taylor Blau <me@ttaylorr.com>,
git@vger.kernel.org
Subject: Re: What's cooking in git.git (Oct 2021, #02; Wed, 6)
Date: Thu, 07 Oct 2021 09:42:11 +0200 [thread overview]
Message-ID: <87sfxdgtpu.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <YV5dmkkuCqAY2qqG@coredump.intra.peff.net>
On Wed, Oct 06 2021, Jeff King wrote:
> On Wed, Oct 06, 2021 at 10:24:40PM -0400, Jeff King wrote:
>
>> On Wed, Oct 06, 2021 at 05:24:14PM -0700, Junio C Hamano wrote:
>>
>> > * tb/repack-write-midx (2021-10-01) 9 commits
>> > (merged to 'next' on 2021-10-06 at ccdd5aaf2a)
>> > + builtin/repack.c: pass `--refs-snapshot` when writing bitmaps
>> > + builtin/repack.c: make largest pack preferred
>> > + builtin/repack.c: support writing a MIDX while repacking
>> > + builtin/repack.c: extract showing progress to a variable
>> > + builtin/repack.c: rename variables that deal with non-kept packs
>> > + builtin/repack.c: keep track of existing packs unconditionally
>> > + midx: preliminary support for `--refs-snapshot`
>> > + builtin/multi-pack-index.c: support `--stdin-packs` mode
>> > + midx: expose `write_midx_file_only()` publicly
>> >
>> > "git repack" has been taught to generate multi-pack reachability
>> > bitmaps.
>> >
>> > Will merge to 'master'.
>>
>> Sorry not to catch this before it hit 'next', but there's a small leak
>> in the test helper. This patch can go on top to fix it.
>
> The reason for that is that I didn't find it by inspection; I've started
> running my personal builds through coverity. It wasn't too bad to set up
> with a GitHub Action, like so:
>
> ---
> .github/workflows/coverity.yml | 35 ++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 .github/workflows/coverity.yml
>
> diff --git a/.github/workflows/coverity.yml b/.github/workflows/coverity.yml
> new file mode 100644
> index 0000000000..bfd4dff275
> --- /dev/null
> +++ b/.github/workflows/coverity.yml
> @@ -0,0 +1,35 @@
> +name: coverity-scan
> +on: push
> +
> +jobs:
> + latest:
> + runs-on: ubuntu-latest
> + steps:
> + - uses: actions/checkout@v2
> + - run: ci/install-dependencies.sh
> + - name: Download Coverity Build Tool
> + run: |
> + wget -q https://scan.coverity.com/download/linux64 --post-data "token=$TOKEN&project=peff/git" -O cov-analysis-linux64.tar.gz
Interesting mix...
> + mkdir cov-analysis-linux64
> + tar xzf cov-analysis-linux64.tar.gz --strip 1 -C cov-analysis-linux64
> + env:
> + TOKEN: ${{ secrets.COVERITY_SCAN_TOKEN }}
> +
> + - name: Build with cov-build
> + run: |
> + export PATH=$(pwd)/cov-analysis-linux64/bin:$PATH
> + cov-build --dir cov-int make
> +
> + - name: Submit the result to Coverity Scan
> + run: |
> + tar czvf git.tgz cov-int
> + curl \
...of curl & wget :)
> + --form project=peff/git \
> + --form token=$TOKEN \
> + --form email=peff@peff.net \
> + --form file=@git.tgz \
> + --form version=$(git rev-parse HEAD) \
> + --form description="$(./git version)" \
> + https://scan.coverity.com/builds?project=peff/git
> + env:
> + TOKEN: ${{ secrets.COVERITY_SCAN_TOKEN }}
>
> Is there interest in having something like this in the main repo? We'd
> need to tweak some values:
I'm very interested in it, it would be great to have more CI targets,
even if optional.
> - we have to send the project name (here peff/git); we can presumably
> get this on the fly from the Actions envir
Our $CI_REPO_SLUG I believe. See
https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables
& a grep for CI_REPO_SLUG in git.git.
> - any repo which wants to use this has to set up the secret token
> (COVERITY_SCAN_TOKEN here). That involves creating a coverity
> account, and then setting the token in the GitHub web interface.
> Presumably we'd just bail immediately if that token isn't set, so
> forks aside from git/git would have to enable it independently.
I tried creating one of these now, requested access at
https://scan.coverity.com/projects/git & it's pending.
Maybe I should have clicked the "connect with GitHub" at the beginning,
but it wanted (ro) ACL access to all organizations I was in, including
private boards or something. So I went for the generic sign-up.
> - likewise it needs the email address for the coverity account. That
> could probably be set in the environment, too.
>
> - we'd probably want to only run it for integration branches, since
> coverity sets some limits on how often it runs. This could probably
> be set in another environment variable, so people could tweak it for
> their forks if they wanted to (or we could use the ci-config hacks,
> but I put those together mostly because these environment variables
> didn't exist back then; I suspect we could switch off of them now).
>
> There are tons of existing warnings, many of which are false positives.
> But it keeps track of which problems are new, and emails out a summary
> of only the new ones (which is how I saw the leak here, which just hit
> next). I don't care all that much about leaks here (we have other
> techniques for finding them), but when Stefan used to do regular
> coverity builds in the past, it routinely found useful errors.
>
> If we had it running on git/git, it's possible for people to subscribe
> to those notifications (or view them on the site; both require the
> people to have coverity accounts, but they're free).
>
> Thoughts?
Sounds good, I wonder if they (if contacted) provide upon request some
community-wide keys for projects such as git, so it would Just Work for
forks without their owners needing to sign up themselves...
next prev parent reply other threads:[~2021-10-07 7:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-07 0:24 What's cooking in git.git (Oct 2021, #02; Wed, 6) Junio C Hamano
2021-10-07 2:01 ` ab/make-sparse-for-real Ævar Arnfjörð Bjarmason
2021-10-07 2:24 ` What's cooking in git.git (Oct 2021, #02; Wed, 6) Jeff King
2021-10-07 2:38 ` Jeff King
2021-10-07 4:07 ` Taylor Blau
2021-10-08 3:55 ` Jeff King
2021-10-08 7:51 ` Johannes Schindelin
2021-10-08 21:32 ` Jeff King
2021-10-20 12:27 ` Johannes Schindelin
2021-10-20 14:30 ` Taylor Blau
2021-10-20 14:47 ` Junio C Hamano
2021-10-20 16:13 ` Jeff King
2022-08-16 9:05 ` Coverity, was " Johannes Schindelin
2022-08-17 0:57 ` Jeff King
2022-08-19 11:22 ` Johannes Schindelin
2021-10-07 7:42 ` Ævar Arnfjörð Bjarmason [this message]
2021-10-08 4:10 ` Jeff King
2021-10-08 20:03 ` Junio C Hamano
2021-10-08 20:19 ` Jeff King
2021-10-08 21:57 ` Junio C Hamano
2021-10-07 2:57 ` Ævar Arnfjörð Bjarmason
2021-10-07 4:15 ` Taylor Blau
2021-10-07 3:55 ` Taylor Blau
2021-10-07 18:02 ` 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=87sfxdgtpu.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=peff@peff.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).