git/.github, branch v2.35.2

Merge branch 'ab/ci-updates'

2021-12-15T17:39:49Z

Drop support for TravisCI and update test workflows at GitHub. * ab/ci-updates: CI: don't run "make test" twice in one job CI: use "$runs_on_pool", not "$jobname" to select packages & config CI: rename the "Linux32" job to lower-case "linux32" CI: use shorter names that fit in UX tooltips CI: remove Travis CI support

Merge branch 'hk/ci-checkwhitespace-commentfix'

2021-12-10T22:35:12Z

Comment fix. * hk/ci-checkwhitespace-commentfix: ci(check-whitespace): update stale file top comments

Merge branch 'js/ci-no-directional-formatting'

2021-12-10T22:35:06Z

CI has been taught to catch some Unicode directional formatting sequence that can be used in certain mischief. * js/ci-no-directional-formatting: ci: disallow directional formatting

CI: don't run "make test" twice in one job

2021-11-24T00:51:54Z

The "linux-clang" and "linux-gcc" jobs both run "make test" twice, but with different environment variables. Running these in sequence seems to have been done to work around some constraint on Travis, see ae59a4e44f3 (travis: run tests with GIT_TEST_SPLIT_INDEX, 2018-01-07). By having these run in parallel we'll get jobs that finish much sooner than they otherwise would have. We can also simplify the control flow in "ci/run-build-and-tests.sh" as a result, since we won't run "make test" twice we don't need to run "make" twice at all, let's default to "make all test" after setting the variables, and then override it to just "all" for the compile-only tests. Add a comment to clarify that new "test" targets should adjust $MAKE_TARGETS rather than being added after the "case/esac". This should avoid future confusion where e.g. the compilation-only "pedantic" target will unexpectedly start running tests. See [1] and [2]. 1. https://lore.kernel.org/git/211122.86ee78yxts.gmgdl@evledraar.gmail.com/ 2. https://lore.kernel.org/git/211123.86ilwjujmd.gmgdl@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

CI: use "$runs_on_pool", not "$jobname" to select packages & config

2021-11-24T00:51:53Z

Change the setup hooks for the CI to use "$runs_on_pool" for the "$regular" job. Now we won't need as much boilerplate when adding new jobs to the "regular" matrix, see 956d2e4639b (tests: add a test mode for SANITIZE=leak, run it in CI, 2021-09-23) for the last such commit. I.e. now instead of needing to enumerate each jobname when we select packages we can install things depending on the pool we're running in. That we didn't do this dates back to the now gone dependency on Travis CI, but even if we add a new CI target in the future this'll be easier to port over, since we can probably treat "ubuntu-latest" as a stand-in for some recent Linux that can run "apt" commands. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

CI: rename the "Linux32" job to lower-case "linux32"

2021-11-24T00:51:53Z

As a follow-up to the preceding commit's shortening of CI job names, rename the only job that starts with an upper-case letter to be consistent with the rest. It was added in 88dedd5e72c (Travis: also test on 32-bit Linux, 2017-03-05). Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

CI: use shorter names that fit in UX tooltips

2021-11-24T00:51:53Z

Change the names used for the GitHub CI workflows to be short enough to (mostly) fit in the pop-up tool-tips that GitHub shows in the commit view. I.e. when mouse-clicking on the passing or failing check-mark next to the commit subject. These names are seemingly truncated to 17-20 characters followed by three dots ("..."). Since a "CI/PR / " prefix is added to them the job names looked like this before (windows-test and vs-test jobs omitted): CI/PR / ci-config (p... CI/PR / windows-buil... CI/PR / vs-build (pu... CI/PR / regular (lin... CI/PR / regular (lin... CI/PR / regular (os... CI/PR / regular (os... CI/PR / regular (lin... CI/PR / regular (lin... CI/PR / dockerized (... CI/PR / dockerized (... CI/PR / dockerized (... CI/PR / static-anal... CI/PR / sparse (pu... CI/PR / documenta... By omitting the "/PR" from the top-level name, and pushing the $jobname to the front we'll now instead get: CI / config (push) CI / win build (push... CI / win+VS build (... CI / linux-clang (ub... CI / linux-gcc (ubun... CI / osx-clang (osx)... CI / osx-gcc (osx) (... CI / linux-gcc-defau... CI / linux-leaks (ub... CI / linux-musl (alp... CI / Linux32 (daald/... CI / pedantic (fedor... CI / static-analysis... CI / sparse (push)... CI / documentation We then have no truncation in the expanded view. See [1] for how it looked before, [2] for a currently visible CI run using this commit, and [3] for the GitHub workflow syntax involved being changed here. Let's also use the existing "pool" field as before. It's occasionally useful to know we're running on say ubuntu v.s. fedora. The "-latest" suffix is useful to some[4], and since it's now at the end it doesn't hurt readability in the short view compared to saying "ubuntu" or "macos". 1. https://github.com/git/git/tree/master/ 2. https://github.com/avar/git/tree/avar/ci-rm-travis-cleanup-ci-names-3 3. https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions 3. https://lore.kernel.org/git/d9b07ca5-b58d-a535-d25b-85d7f12e6295@github.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

ci(check-whitespace): update stale file top comments

2021-11-19T22:45:33Z

Earlier a066a90d (ci(check-whitespace): restrict to the intended commits, 2021-07-14) changed the check-whitespace task to stop using a shallow clone, and cc003621 (ci(check-whitespace): stop requiring a read/write token, 2021-07-14) changed the way how the errors the task discovered is signaled back to the user. They however forgot to update the comment that outlines what is done in the task. Correct them. Signed-off-by: Hans Krentel (hakre) Signed-off-by: Junio C Hamano

ci: disallow directional formatting

2021-11-04T17:13:10Z

As described in https://trojansource.codes/trojan-source.pdf, it is possible to abuse directional formatting (a feature of Unicode) to deceive human readers into interpreting code differently from compilers. For example, an "if ()" expression could be enclosed in a comment, but rendered as if it was outside of that comment. In effect, this could fool a reviewer into misinterpreting the code flow as benign when it is not. It is highly unlikely that Git's source code wants to contain such directional formatting in the first place, so let's just disallow it. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Merge branch 'js/windows-ci-path-fix'

2021-10-18T22:47:58Z

The PATH used in CI job may be too wide and let incompatible dlls to be grabbed, which can cause the build&test to fail. Tighten it. * js/windows-ci-path-fix: ci(windows): ensure that we do not pick up random executables