git/ci/lib.sh, branch v2.32.2

ci: remove GETTEXT_POISON jobs

2021-01-21T23:50:00Z

A subsequent commit will remove GETTEXT_POISON entirely, let's start by removing the CI jobs that enable the option. We cannot just remove the job because the CI is implicitly depending on the "poison" job being a sort of "default" job in the sense that it's the job that was otherwise run with the default compiler, no other GIT_TEST_* options etc. So let's keep it under the name "linux-gcc-default". This means we can remove the initial "make test" from the "linux-gcc" job (it does another one after setting a bunch of GIT_TEST_* variables). I'm not doing that because it would conflict with the in-flight 334afbc76fb (tests: mark tests relying on the current default for `init.defaultBranch`, 2020-11-18) (currently on the "seen" branch, so the SHA-1 will almost definitely change). It's going to use that "make test" again for different reasons, so let's preserve it for now. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

ci: do not skip tagged revisions in GitHub workflows

2020-10-08T18:58:41Z

When `master` is tagged, and then both `master` and the tag are pushed, Travis CI will happily build both. That is a waste of energy, which is why we skip the build for `master` in that case. Our GitHub workflow is also triggered by tags. However, the run would fail because the `windows-test` jobs are _not_ skipped on tags, but the `windows-build` job _is skipped (and therefore fails to upload the build artifacts needed by the test jobs). In addition, we just added logic to our GitHub workflow that will skip runs altogether if there is already a successful run for the same commit or at least for the same tree. Let's just change the GitHub workflow to no longer specifically skip tagged revisions. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: stop linking built-ins to the dashed versions

2020-09-21T22:47:54Z

Since e4597aae6590 (run test suite without dashed git-commands in PATH, 2009-12-02), we stopped running our tests with `git-foo` binaries found at the top-level directory of a freshly built source tree; instead we have placed only `git` and selected `git-foo` commands that must be on `$PATH` in `bin-wrappers/` and prepended that `bin-wrappers/` to the `PATH` used in the test suite. We did that to catch the tests and scripted Git commands that still try to use the dashed form. Since CI jobs will not install the built Git to anywhere, and the hardlinks we make at the top-level of the source tree for `git-add` and friends are not even used during tests, they are pure waste of resources these days. Thanks to the newly invented `SKIP_DASHED_BUILT_INS` knob, we can now skip creating these links in the source tree. So let's do that. Note that this change introduces a subtle change of behavior: when Git's `cmd_main()` calls `setup_path()`, it inserts the value of `GIT_EXEC_PATH` (defaulting to `/libexec/git-core`) at the beginning of the environment variable `PATH`. This is necessary to find e.g. scripted commands that are installed in that location. For the purposes of Git's test suite, the `bin-wrappers/` scripts override `GIT_EXEC_PATH` to point to the top-level directory of the source code. In other words, if a scripted command had used a dashed invocation of a built-in Git command, it would not have been caught previously, which is fixed by this change. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

ci: use absolute PYTHON_PATH in the Linux jobs

2020-07-23T22:32:06Z

In our test suite, when 'git p4' invokes a Git command as a subprocesses, then it should run the 'git' binary we are testing. Unfortunately, this is not the case in the 'linux-clang' and 'linux-gcc' jobs on Travis CI, where 'git p4' runs the system '/usr/bin/git' instead. Travis CI's default Linux image includes 'pyenv', and all Python invocations that involve PATH lookup go through 'pyenv', e.g. our 'PYTHON_PATH=$(which python3)' sets '/opt/pyenv/shims/python3' as PYTHON_PATH, which in turn will invoke '/usr/bin/python3'. Alas, the 'pyenv' version included in this image is buggy, and prepends the directory containing the Python binary to PATH even if that is a system directory already in PATH near the end. Consequently, 'git p4' in those jobs ends up with its PATH starting with '/usr/bin', and then runs '/usr/bin/git'. So use the absolute paths '/usr/bin/python{2,3}' explicitly when setting PYTHON_PATH in those Linux jobs to avoid the PATH lookup and thus the bogus 'pyenv' from interfering with our 'git p4' tests. Don't bother with special-casing Travis CI: while this issue doesn't affect the corresponding Linux jobs on GitHub Actions, both CI systems use Ubuntu LTS-based images, so we can safely rely on these Python paths. Signed-off-by: SZEDER Gábor Signed-off-by: Junio C Hamano

Revert "ci: add a problem matcher for GitHub Actions"

2020-05-15T17:25:58Z

This reverts commit 676eb0c1ce0d380478eb16bdc5a3f2a7bc01c1d2; as we will be reverting the change to show these extra output tokens under bash, the pattern would not match anything. Helped-by: Carlo Marcelo Arenas Belón Signed-off-by: Junio C Hamano

ci: add a problem matcher for GitHub Actions

2020-04-10T17:30:40Z

With this patch, test failures will be annotated with a helpful, clickable message in GitHub Actions. For details, see https://github.com/actions/toolkit/blob/master/docs/problem-matchers.md Note: we need to set `TEST_SHELL_PATH` to Bash so that the problem matcher is fed a file and line number for each test failure. Signed-off-by: Johannes Schindelin Signed-off-by: Đoàn Trần Công Danh Signed-off-by: Junio C Hamano

ci: fix the `jobname` of the `GETTEXT_POISON` job

2020-04-08T05:17:10Z

In 6cdccfce1e0f (i18n: make GETTEXT_POISON a runtime option, 2018-11-08), the `jobname` was adjusted to have the `GIT_TEST_` prefix, but that prefix makes no sense in this context. Co-authored-by: Đoàn Trần Công Danh Signed-off-by: Johannes Schindelin Signed-off-by: Đoàn Trần Công Danh Signed-off-by: Junio C Hamano

ci/lib: set TERM environment variable if not exist

2020-04-08T05:17:10Z

GitHub Action doesn't set TERM environment variable, which is required by "tput". Fallback to dumb if it's not set. Signed-off-by: Đoàn Trần Công Danh Signed-off-by: Junio C Hamano

ci/lib: allow running in GitHub Actions

2020-04-08T05:17:10Z

For each CI system we support, we need a specific arm in that if/else construct in ci/lib.sh. Let's add one for GitHub Actions. Signed-off-by: Johannes Schindelin Signed-off-by: Đoàn Trần Công Danh Signed-off-by: Junio C Hamano

ci/lib: if CI type is unknown, show the environment variables

2020-04-08T05:17:10Z

This should help with adding new CI-specific if-else arms. Signed-off-by: Johannes Schindelin Signed-off-by: Đoàn Trần Công Danh Signed-off-by: Junio C Hamano