Message ID | pull.1588.v2.git.1695642662.gitgitgadget@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Add a GitHub workflow to submit builds to Coverity Scan | expand |
On Mon, Sep 25, 2023 at 11:50:56AM +0000, Johannes Schindelin via GitGitGadget wrote: > Changes since v1: > > * After verifying that cURL's --fail option does what we need in Coverity's > context, I switched to using that in every curl invocation. > * Adjusted quoting (the ${{ ... }} constructs do not require double quotes > because they are interpolated before the script is run). > * Touched up a few commit messages, based on the feedback I received. > * Addressed an actionlint [https://rhysd.github.io/actionlint/] warning. Thanks, this looks fine to me. The only other comment is the same one I made for Taylor's version: that COVERITY_SCAN_EMAIL could probably be a "var" and not a "secret". Though the main advantage there (besides it being a little easier for the user to edit in the web UI) is that it could be used in the jobs.*.if context (to skip the job in unconfigured repos). But since your "if" uses a default-disallow when ENABLE_COVERITY_SCAN_FOR_BRANCHES is not set, it is not that important to check COVERITY_SCAN_EMAIL. -Peff
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > Coverity [https://scan.coverity.com/] is a powerful static analysis tool > that helps prevent vulnerabilities. It is free to use by open source > projects, and Git benefits from this, as well as Git for Windows. As is the > case with many powerful tools, using Coverity comes with its own set of > challenges, one of which being that submitting a build is quite laborious. > ... One thing that caught my eye was the asterisks around "22" that look as if they were designed to confuse readers and cause them wonder if there are other codes like 122 and 224 that we would also want to catch there. Unless they know what the case statement replaced, that is---the old code to match http_code that was scraped from a text file may not have the code alone and may contain other cruft, so it is entirely understandable, but the new one checks $? and there is no reason other than to catch 122 and 224 to use *22*. > -+ http_code="$(sed -n 1p <"$RUNNER_TEMP"/headers.txt)" > -+ case "$http_code" in > -+ *200*) ;; # okay > -+ *401*) # access denied > -+ echo "::error::incorrect token or project? ($http_code)" >&2 > + --fail \ > + --form token='${{ secrets.COVERITY_SCAN_TOKEN }}' \ > + --form project="$COVERITY_PROJECT" \ > +- --form md5=1) && > ++ --form md5=1) > ++ case $? in > ++ 0) ;; # okay > ++ *22*) # 40x, i.e. access denied > ++ echo "::error::incorrect token or project?" >&2 > + exit 1 > + ;; > + *) # other error > -+ echo "::error::HTTP error $http_code" >&2 > ++ echo "::error::Failed to retrieve MD5" >&2 > + exit 1 > + ;; > + esac Other than that, while I was watching from the sideline, I am very happy to see that you, with Peff's constructive input, came up with a new iteration that looks simpler and more consistent in its use of curl. Will replace but I may be tempted to edit those asterisks out myself while queueing. Thanks.
Hi Junio, On Mon, 25 Sep 2023, Junio C Hamano wrote: > One thing that caught my eye was the asterisks around "22" that look > as if they were designed to confuse readers [...] > > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> > writes: > > > [...] > > ++ case $? in > > ++ 0) ;; # okay > > ++ *22*) # 40x, i.e. access denied > > ++ echo "::error::incorrect token or project?" >&2 > > + exit 1 > > + ;; > > [...] > > Will replace but I may be tempted to edit those asterisks out myself > while queueing. D'oh, of course. Thank you, Johannes