git/.github/workflows, branch v2.34.2

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

Merge branch 'js/retire-preserve-merges'

2021-10-18T22:47:56Z

The "--preserve-merges" option of "git rebase" has been removed. * js/retire-preserve-merges: sequencer: restrict scope of a formerly public function rebase: remove a no-longer-used function rebase: stop mentioning the -p option in comments rebase: remove obsolete code comment rebase: drop the internal `rebase--interactive` command git-svn: drop support for `--preserve-merges` rebase: drop support for `--preserve-merges` pull: remove support for `--rebase=preserve` tests: stop testing `git rebase --preserve-merges` remote: warn about unhandled branch..rebase values t5520: do not use `pull.rebase=preserve`

ci(windows): ensure that we do not pick up random executables

2021-10-13T17:36:17Z

On the Windows build agents, a lot of programs are installed, and added to the PATH automatically. One such program is Git for Windows, and due to the way it is set up, unfortunately its copy of `gpg.exe` is also reachable via the PATH. This usually does not pose any problems. To the contrary, it even allows us to test the GPG parts of Git's test suite even if `gpg.exe` is not delivered as part of `git-sdk-64-minimal`, the minimal subset of Git for Windows' SDK that we use in the CI builds to compile Git. However, every once in a while we build a new MSYS2 runtime, which means that there is a mismatch between the copy in `git-sdk-64-minimal` and the copy in C:\Program Files\Git\usr\bin. When that happens we hit the dreaded problem where only one `msys-2.0.dll` is expected to be in the PATH, and things start to fail. Let's avoid all of this by restricting the PATH to the minimal set. This is actually done by `git-sdk-64-minimal`'s `/etc/profile`, and we just have to source this file manually (one would expect that it is sourced automatically, but the Bash steps in Azure Pipelines/GitHub workflows are explicitly run using `--noprofile`, hence the need for doing this explicitly). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

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

Merge branch 'ab/sanitize-leak-ci'

2021-10-11T17:21:47Z

CI learns to run the leak sanitizer builds. * ab/sanitize-leak-ci: tests: add a test mode for SANITIZE=leak, run it in CI Makefile: add SANITIZE=leak flag to GIT-BUILD-OPTIONS

Merge branch 'jx/ci-l10n'

2021-10-04T04:49:17Z

CI help for l10n. * jx/ci-l10n: ci: new github-action for git-l10n code review

tests: add a test mode for SANITIZE=leak, run it in CI

2021-09-23T18:29:45Z

While git can be compiled with SANITIZE=leak, we have not run regression tests under that mode. Memory leaks have only been fixed as one-offs without structured regression testing. This change adds CI testing for it. We'll now build and small set of whitelisted t00*.sh tests under Linux with a new job called "linux-leaks". The CI target uses a new GIT_TEST_PASSING_SANITIZE_LEAK=true test mode. When running in that mode, we'll assert that we were compiled with SANITIZE=leak. We'll then skip all tests, except those that we've opted-in by setting "TEST_PASSES_SANITIZE_LEAK=true". A test setting "TEST_PASSES_SANITIZE_LEAK=true" setting can in turn make use of the "SANITIZE_LEAK" prerequisite, should they wish to selectively skip tests even under "GIT_TEST_PASSING_SANITIZE_LEAK=true". In the preceding commit we started doing this in "t0004-unwritable.sh" under SANITIZE=leak, now it'll combine nicely with "GIT_TEST_PASSING_SANITIZE_LEAK=true". This is how tests that don't set "TEST_PASSES_SANITIZE_LEAK=true" will be skipped under GIT_TEST_PASSING_SANITIZE_LEAK=true: $ GIT_TEST_PASSING_SANITIZE_LEAK=true ./t0001-init.sh 1..0 # SKIP skip all tests in t0001 under SANITIZE=leak, TEST_PASSES_SANITIZE_LEAK not set The intent is to add more TEST_PASSES_SANITIZE_LEAK=true annotations as follow-up change, but let's start small to begin with. In ci/run-build-and-tests.sh we make use of the default "*" case to run "make test" without any GIT_TEST_* modes. SANITIZE=leak is known to fail in combination with GIT_TEST_SPLIT_INDEX=true in t0016-oidmap.sh, and we're likely to have other such failures in various GIT_TEST_* modes. Let's focus on getting the base tests passing, we can expand coverage to GIT_TEST_* modes later. It would also be possible to implement a more lightweight version of this by only relying on setting "LSAN_OPTIONS". See [1] and [2] for a discussion of that. I've opted for this approach of adding a GIT_TEST_* mode instead because it's consistent with how we handle other special test modes. Being able to add a "!SANITIZE_LEAK" prerequisite and calling "test_done" early if it isn't satisfied also means that we can more incrementally add regression tests without being forced to fix widespread and hard-to-fix leaks at the same time. We have tests that do simple checking of some tool we're interested in, but later on in the script might be stressing trace2, or common sources of leaks like "git log" in combination with the tool (e.g. the commit-graph tests). To be clear having a prerequisite could also be accomplished by using "LSAN_OPTIONS" directly. On the topic of "LSAN_OPTIONS": It would be nice to have a mode to aggregate all failures in our various scripts, see [2] for a start at doing that which sets "log_path" in "LSAN_OPTIONS". I've punted on that for now, it can be added later. As of writing this we've got major regressions between master..seen, i.e. the t000*.sh tests and more fixed since 31f9acf9ce2 (Merge branch 'ah/plugleaks', 2021-08-04) have regressed recently. See the discussion at <87czsv2idy.fsf@evledraar.gmail.com>[3] about the lack of this sort of test mode, and 0e5bba53af (add UNLEAK annotation for reducing leak false positives, 2017-09-08) for the initial addition of SANITIZE=leak. See also 09595ab381 (Merge branch 'jk/leak-checkers', 2017-09-19), 7782066f67 (Merge branch 'jk/apache-lsan', 2019-05-19) and the recent 936e58851a (Merge branch 'ah/plugleaks', 2021-05-07) for some of the past history of "one-off" SANITIZE=leak (and more) fixes. As noted in [5] we can't support this on OSX yet until Clang 14 is released, at that point we'll probably want to resurrect that "osx-leaks" job. 1. https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer 2. https://lore.kernel.org/git/YS9OT%2Fpn5rRK9cGB@coredump.intra.peff.net/ 3. https://lore.kernel.org/git/87czsv2idy.fsf@evledraar.gmail.com/ 4. https://lore.kernel.org/git/YS9ZIDpANfsh7N+S@coredump.intra.peff.net/ 5. https://lore.kernel.org/git/20210916035603.76369-1-carenas@gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Carlo Marcelo Arenas Belón Signed-off-by: Junio C Hamano

Merge branch 'cb/ci-build-pedantic'

2021-09-10T18:46:32Z

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

ci: new github-action for git-l10n code review

2021-09-09T19:55:21Z

The repository of git-l10n is a fork of "git/git" on GitHub, and uses GitHub pull request for code review. A helper program "git-po-helper" can be used to check typos in ".po" files, validate syntax, and check commit messages. It would be convenient to integrate this helper program to CI and add comments in pull request. The new github-action workflow will be enabled for l10n related operations, such as: * Operations on a repository named as "git-po", such as a repository forked from "git-l10n/git-po". * Push to a branch that contains "l10n" in the name. * Pull request from a remote branch which has "l10n" in the name, such as: "l10n/fix-fuzzy-translations". The new l10n workflow listens to two types of github events: on: [push, pull_request_target] The reason we use "pull_request_target" instead of "pull_request" is that pull requests from forks receive a read-only GITHUB_TOKEN and workflows cannot write comments back to pull requests for security reasons. GitHub provides a "pull_request_target" event to resolve security risks by checking out the base commit from the target repository, and provide write permissions for the workflow. By default, administrators can set strict permissions for workflows. The following code is used to modify the permissions for the GITHUB_TOKEN and grant write permission in order to create comments in pull-requests. permissions: pull-requests: write This workflow will scan commits one by one. If a commit does not look like a l10n commit (no file in "po/" has been changed), the scan process will stop immediately. For a "push" event, no error will be reported because it is normal to push non-l10n commits merged from upstream. But for the "pull_request_target" event, errors will be reported. For this reason, additional option is provided for "git-po-helper". git-po-helper check-commits \ --github-action-event="${{ github.event_name }}" -- \ .. The output messages of "git-po-helper" contain color codes not only for console, but also for logfile. This is because "git-po-helper" uses a package named "logrus" for logging, and I use an additional option "ForceColor" to initialize "logrus" to print messages in a user-friendly format in logfile output. These color codes help produce beautiful output for the log of workflow, but they must be stripped off when creating comments for pull requests. E.g.: perl -pe 's/\e\[[0-9;]*m//g' git-po-helper.out "git-po-helper" may generate two kinds of suggestions, errors and warnings. All the errors and warnings will be reported in the log of the l10n workflow. However, warnings in the log of the workflow for a successfully running "git-po-helper" can easily be ignored by users. For the "pull_request_target" event, this issue is resolved by creating an additional comment in the pull request. A l10n contributor should try to fix all the errors, and should pay attention to the warnings. Helped-by: Johannes Schindelin Signed-off-by: Jiang Xin Signed-off-by: Junio C Hamano