git/.github/workflows, branch v2.43.2

ci: upgrade to using macos-13

2023-11-03T09:52:02Z

In April, GitHub announced that the `macos-13` pool is available: https://github.blog/changelog/2023-04-24-github-actions-macos-13-is-now-available/. It is only a matter of time until the `macos-12` pool is going away, therefore we should switch now, without pressure of a looming deadline. Since the `macos-13` runners no longer include Python2, we also drop specifically testing with Python2 and switch uniformly to Python3, see https://github.com/actions/runner-images/blob/HEAD/images/macos/macos-13-Readme.md for details about the software available on the `macos-13` pool's runners. Also, on macOS 13, Homebrew seems to install a `gcc@9` package that no longer comes with a regular `unistd.h` (there seems only to be a `ssp/unistd.h`), and hence builds would fail with: In file included from base85.c:1: git-compat-util.h:223:10: fatal error: unistd.h: No such file or directory 223 | #include | ^~~~~~~~~~ compilation terminated. The reason why we install GCC v9.x explicitly is historical, and back in the days it was because it was the _newest_ version available via Homebrew: 176441bfb58 (ci: build Git with GCC 9 in the 'osx-gcc' build job, 2019-11-27). To reinstate the spirit of that commit _and_ to fix that build failure, let's switch to the now-newest GCC version: v13.x. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'jk/ci-retire-allow-ref' into maint-2.42

2023-11-02T07:53:23Z

CI update. * jk/ci-retire-allow-ref: ci: deprecate ci/config/allow-ref script ci: allow branch selection through "vars"

Merge branch 'jc/ci-skip-same-commit' into maint-2.42

2023-11-02T07:53:15Z

Tweak GitHub Actions CI so that pushing the same commit to multiple branch tips at the same time will not waste building and testing the same thing twice. * jc/ci-skip-same-commit: ci: avoid building from the same commit in parallel

coverity: detect and report when the token or project is incorrect

2023-10-05T18:45:46Z

When trying to obtain the MD5 of the Coverity Scan Tool (in order to decide whether a cached version can be used or a new version has to be downloaded), it is possible to get a 401 (Authorization required) due to either an incorrect token, or even more likely due to an incorrect Coverity project name. Seeing an authorization failure that is caused by an incorrect project name was somewhat surprising to me when developing the Coverity workflow, as I found such a failure suggestive of an incorrect token instead. So let's provide a helpful error message about that specifically when encountering authentication issues. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

coverity: allow running on macOS

2023-09-25T17:12:49Z

For completeness' sake, let's add support for submitting macOS builds to Coverity Scan. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

coverity: support building on Windows

2023-09-25T17:12:49Z

By adding the repository variable `ENABLE_COVERITY_SCAN_ON_OS` with a value, say, `["windows-latest"]`, this GitHub workflow now runs on Windows, allowing to analyze Windows-specific issues. This allows, say, the Git for Windows fork to submit Windows builds to Coverity Scan instead of Linux builds. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

coverity: allow overriding the Coverity project

2023-09-25T17:12:49Z

By default, the builds are submitted to the `git` project at https://scan.coverity.com/projects/git. The Git for Windows project would like to use this workflow, too, though, and needs the builds to be submitted to the `git-for-windows` Coverity project. To that end, allow configuring the Coverity project name via the repository variable, you guessed it, `COVERITY_PROJECT`. The default if that variable is not configured or has an empty value is still `git`. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

coverity: cache the Coverity Build Tool

2023-09-25T17:12:48Z

It would add a 1GB+ download for every run, better cache it. This is inspired by the GitHub Action `vapier/coverity-scan-action`, however, it uses the finer-grained `restore`/`save` method to be able to cache the Coverity Build Tool even if an unrelated step in the GitHub workflow fails later on. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: add a GitHub workflow to submit Coverity scans

2023-09-25T17:12:48Z

Coverity is a static analysis tool that detects and generates reports on various security and code quality issues. It is particularly useful when diagnosing memory safety issues which may be used as part of exploiting a security vulnerability. Coverity's website provides a service that accepts "builds" (which contains the object files generated during a standard build as well as a database generated by Coverity's scan tool). Let's add a GitHub workflow to automate all of this. To avoid running it without appropriate Coverity configuration (e.g. the token required to use Coverity's services), the job only runs when the repository variable "ENABLE_COVERITY_SCAN_FOR_BRANCHES" has been configured accordingly (see https://docs.github.com/en/actions/learn-github-actions/variables for details how to configure repository variables): It is expected to be a valid JSON array of branch strings, e.g. `["main", "next"]`. In addition, this workflow requires two repository secrets: - COVERITY_SCAN_EMAIL: the email to send the report to, and - COVERITY_SCAN_TOKEN: the Coverity token (look in the Project Settings tab of your Coverity project). Note: The initial version of this patch used `vapier/coverity-scan-action` to benefit from that Action's caching of the Coverity tool, which is rather large. Sadly, that Action only supports Linux, and we want to have the option of building on Windows, too. Besides, in the meantime Coverity requires `cov-configure` to be runantime, and that Action was not adjusted accordingly, i.e. it seems not to be maintained actively. Therefore it would seem prudent to implement the steps manually instead of using that Action. Initial-patch-by: Taylor Blau Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: deprecate ci/config/allow-ref script

2023-08-30T22:56:11Z

Now that we have the CI_BRANCHES mechanism, there is no need for anybody to use the ci/config/allow-ref mechanism. In the long run, we can hopefully remove it and the whole "config" job, as it consumes CPU and adds to the end-to-end latency of the whole workflow. But we don't want to do that immediately, as people need time to migrate until the CI_BRANCHES change has made it into the workflow file of every branch. So let's issue a warning, which will appear in the "annotations" section below the workflow result in GitHub's web interface. And let's remove the sample allow-refs script, as we don't want to encourage anybody to use it. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano