git/ci/run-static-analysis.sh

35 lines
513 B
Bash
Raw Normal View History

#!/bin/sh
#
# Perform various static code analysis checks
#
. ${0%/*}/lib.sh
make coccicheck
travis-ci: record and skip successfully built trees Travis CI dutifully builds and tests each new branch tip, even if its tree has previously been successfully built and tested. This happens often enough in contributors' workflows, when a work-in-progress branch is rebased changing e.g. only commit messages or the order or number of commits while leaving the resulting code intact, and is then pushed to a Travis CI-enabled GitHub fork. This is wasting Travis CI's resources and is sometimes scary-annoying when the new tip commit with a tree identical to the previous, successfully tested one is suddenly reported in red, because one of the OSX build jobs happened to exceed the time limit yet again. So extend our Travis CI build scripts to skip building commits whose trees have previously been successfully built and tested. Use the Travis CI cache feature to keep a record of the object names of trees that tested successfully, in a plain and simple flat text file, one line per tree object name. Append the current tree's object name at the end of every successful build job to this file, along with a bit of additional info about the build job (commit object name, Travis CI job number and id). Limit the size of this file to 1000 records, to prevent it from growing too large for git/git's forever living integration branches. Check, using a simple grep invocation, in each build job whether the current commit's tree is already in there, and skip the build if it is. Include a message in the skipped build job's trace log, containing the URL to the build job successfully testing that tree for the first time and instructions on how to force a re-build. Catch the case when a build job, which successfully built and tested a particular tree for the first time, is restarted and omit the URL of the previous build job's trace log, as in this case it's the same build job and the trace log has just been overwritten. Note: this won't kick in if two identical trees are on two different branches, because Travis CI caches are not shared between build jobs of different branches. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Reviewed-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-31 10:12:05 +00:00
travis-ci: fail if Coccinelle static analysis found something to transform Coccinelle's and in turn 'make coccicheck's exit code only indicates that Coccinelle managed to finish its analysis without any errors (e.g. no unknown --options, no missing files, no syntax errors in the semantic patches, etc.), but it doesn't indicate whether it found any undesired code patterns to transform or not. To find out the latter, one has to look closer at 'make coccicheck's standard output and look for lines like: SPATCH result: contrib/coccinelle/<something>.cocci.patch And this only indicates that there is something to transform, but to see what the suggested transformations are one has to actually look into those '*.cocci.patch' files. This makes the automated static analysis build job on Travis CI not particularly useful, because it neither draws our attention to Coccinelle's findings, nor shows the actual findings. Consequently, new topics introducing undesired code patterns graduated to master on several occasions without anyone noticing. The only way to draw attention in such an automated setting is to fail the build job. Therefore, modify the 'ci/run-static-analysis.sh' build script to check all the resulting '*.cocci.patch' files, and fail the build job if any of them turns out to be not empty. Include those files' contents, i.e. Coccinelle's suggested transformations, in the build job's trace log, so we'll know why it failed. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-23 13:02:30 +00:00
set +x
fail=
for cocci_patch in contrib/coccinelle/*.patch
do
if test -s "$cocci_patch"
then
echo "$(tput setaf 1)Coccinelle suggests the following changes in '$cocci_patch':$(tput sgr0)"
cat "$cocci_patch"
fail=UnfortunatelyYes
fi
done
if test -n "$fail"
then
echo "$(tput setaf 1)error: Coccinelle suggested some changes$(tput sgr0)"
exit 1
fi
make hdr-check ||
exit 1
i18n CI: stop allowing non-ASCII source messages in po/git.pot In the preceding commit we moved away from using xgettext(1) to both generate the po/git.pot, and to merge the incrementally generated po/git.pot+ file as we sourced translations from C, shell and Perl. Doing it this way, which dates back to my initial implementation[1][2][3] was conflating two things: With xgettext(1) the --from-code both controls what encoding is specified in the po/git.pot's header, and what encoding we allow in source messages. We don't ever want to allow non-ASCII in *source messages*, and doing so has hid e.g. a buggy message introduced in a6226fd772b (submodule--helper: convert the bulk of cmd_add() to C, 2021-08-10) from us, we'd warn about it before, but only when running "make pot", but the operation would still succeed. Now we'll error out on it when running "make pot". Since the preceding Makefile changes made this easy: let's add a "make check-pot" target with the same prerequisites as the "po/git.pot" target, but without changing the file "po/git.pot". Running it as part of the "static-analysis" CI target will ensure that we catch any such issues in the future. E.g.: $ make check-pot XGETTEXT .build/pot/po/builtin/submodule--helper.c.po xgettext: Non-ASCII string at builtin/submodule--helper.c:3381. Please specify the source encoding through --from-code. make: *** [.build/pot/po/builtin/submodule--helper.c.po] Error 1 1. cd5513a7168 (i18n: Makefile: "pot" target to extract messages marked for translation, 2011-02-22) 2. adc3b2b2767 (Makefile: add xgettext target for *.sh files, 2011-05-14) 3. 5e9637c6297 (i18n: add infrastructure for translating Git with gettext, 2011-11-18) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-26 14:50:29 +00:00
make check-pot
travis-ci: record and skip successfully built trees Travis CI dutifully builds and tests each new branch tip, even if its tree has previously been successfully built and tested. This happens often enough in contributors' workflows, when a work-in-progress branch is rebased changing e.g. only commit messages or the order or number of commits while leaving the resulting code intact, and is then pushed to a Travis CI-enabled GitHub fork. This is wasting Travis CI's resources and is sometimes scary-annoying when the new tip commit with a tree identical to the previous, successfully tested one is suddenly reported in red, because one of the OSX build jobs happened to exceed the time limit yet again. So extend our Travis CI build scripts to skip building commits whose trees have previously been successfully built and tested. Use the Travis CI cache feature to keep a record of the object names of trees that tested successfully, in a plain and simple flat text file, one line per tree object name. Append the current tree's object name at the end of every successful build job to this file, along with a bit of additional info about the build job (commit object name, Travis CI job number and id). Limit the size of this file to 1000 records, to prevent it from growing too large for git/git's forever living integration branches. Check, using a simple grep invocation, in each build job whether the current commit's tree is already in there, and skip the build if it is. Include a message in the skipped build job's trace log, containing the URL to the build job successfully testing that tree for the first time and instructions on how to force a re-build. Catch the case when a build job, which successfully built and tested a particular tree for the first time, is restarted and omit the URL of the previous build job's trace log, as in this case it's the same build job and the trace log has just been overwritten. Note: this won't kick in if two identical trees are on two different branches, because Travis CI caches are not shared between build jobs of different branches. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Reviewed-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-31 10:12:05 +00:00
save_good_tree