git/.github/workflows, branch v2.33.6

Merge branch 'cb/ci-use-upload-artifacts-v1' into maint

2021-10-12T20:51:38Z

Use upload-artifacts v1 (instead of v2) for 32-bit linux, as the new version has a blocker bug for that architecture. * cb/ci-use-upload-artifacts-v1: ci: use upload-artifacts v1 for dockerized jobs

Merge branch 'cb/ci-build-pedantic' into maint

2021-10-12T20:51:31Z

CI update. * cb/ci-build-pedantic: ci: run a pedantic build as part of the GitHub workflow

ci: use upload-artifacts v1 for dockerized jobs

2021-08-15T16:45:38Z

e9f79acb28 (ci: upgrade to using actions/{up,down}load-artifacts v2, 2021-06-23) changed all calls to that action from v1 to v2, but there is still an open bug[1] that affects all nodejs actions and prevents its use in 32-bit linux (as used by the Linux32 container) move all dockerized jobs to use v1 that was built in C# and therefore doesn't have this problem, which will otherwise manifest with confusing messages like: /usr/bin/docker exec 0285adacc4536b7cd962079c46f85fa05a71e66d7905b5e4b9b1a0e8b305722a sh -c "cat /etc/*release | grep ^ID" OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: no such file or directory: unknown [1] https://github.com/actions/runner/issues/1011 Signed-off-by: Carlo Marcelo Arenas Belón Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: run a pedantic build as part of the GitHub workflow

2021-08-11T18:25:06Z

similar to the recently added sparse task, it is nice to know as early as possible. add a dockerized build using fedora (that usually has the latest gcc) to be ahead of the curve and avoid older ISO C issues at the same time. Signed-off-by: Carlo Marcelo Arenas Belón Signed-off-by: Junio C Hamano

Merge branch 'js/ci-check-whitespace-updates'

2021-08-02T21:06:40Z

CI update. * js/ci-check-whitespace-updates: ci(check-whitespace): restrict to the intended commits ci(check-whitespace): stop requiring a read/write token

Merge branch 'js/ci-make-sparse'

2021-07-28T20:18:01Z

The CI gained a new job to run "make sparse" check. * js/ci-make-sparse: ci/install-dependencies: handle "sparse" job package installs ci: run "apt-get update" before "apt-get install" ci: run `make sparse` as part of the GitHub workflow

ci/install-dependencies: handle "sparse" job package installs

2021-07-26T22:20:51Z

This just matches the style/location of the package installation for other jobs. There should be no functional change. I did flip the order of the options and command-name ("-y update" instead of "update -y") for consistency with other lines in the same file. Note also that we have to reorder the dependency install with the "checkout" action, so that we actually have the "ci" scripts available. Signed-off-by: Jeff King Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: run "apt-get update" before "apt-get install"

2021-07-26T22:20:37Z

The "sparse" workflow runs "apt-get install" to pick up a few necessary packages. But it needs to run "apt-get update" first, or it risks trying to download an old package version that no longer exists. And in fact this happens now, with output like: 2021-07-26T17:40:51.2551880Z E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/c/curl/libcurl4-openssl-dev_7.68.0-1ubuntu2.5_amd64.deb 404 Not Found [IP: 52.147.219.192 80] 2021-07-26T17:40:51.2554304Z E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Our other ci jobs don't suffer from this; they rely on scripts in ci/, and ci/install-dependencies does the appropriate "apt-get update". Signed-off-by: Jeff King Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci(check-whitespace): restrict to the intended commits

2021-07-14T22:38:01Z

During a run of the `check-whitespace` we want to verify that the commits introduced in the Pull Request have no whitespace issues. We only want to look at those commits, not the upstream commits (because the contributor cannot do anything about the latter). However, by using the `-` form in `git log --check`, we run the risk of looking at the wrong commits. The reason is that the `actions/checkout` step does _not_ check out the tip commit of the Pull Request's branch: Instead, it checks out a merge commit that merges that branch into the target branch. For that reason, we already adjust the commit count by incrementing it, but that is not enough: if the upstream branch has newer commits, they are traversed _first_. And obviously we will then miss some of the commits that we _actually_ wanted to look at. Therefore, let's be careful to stop assuming a linear, up to date commit topology in the contributed commits, and instead specify the correct commit range. Unfortunately, this means that we no longer can rely on a shallow clone: There is no way of knowing just how many commits the upstream branch advanced after the commit from which the PR branch branched off. So let's just go with a full clone instead, and be safe rather than sorry (if we have "too shallow" a situation, a commit range `@{u}..` may very well include a shallow commit itself, and the output of `git show --check ` is _not_ pretty). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci(check-whitespace): stop requiring a read/write token

2021-07-14T22:37:59Z

As part of some recent security tightening, GitHub introduced the ability to configure GitHub workflows to be run with a read-only token. This is much more secure, in particular when working in a public repository: While the regular read/write token might be restricted to writing to the current branch, it is not necessarily restricted to access only the current Pull Request. However, the `check-whitespace` workflow threw a wrench into this plan: it _requires_ write access (because it wants to add a PR comment in case of a whitespace issue). Let's just skip that PR comment. The user can always click through to the actual error, even if it is slightly less convenient. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano