git/ci, branch v2.30.2

ci/install-depends: attempt to fix "brew cask" stuff

2021-01-15T03:08:56Z

We run "git pull" against "$cask_repo"; clarify that we are expecting not to have any of our own modifications and running "git pull" to merely update, by passing "--ff-only" on the command line. Also, the "brew cask install" command line triggers an error message that says: Error: Calling brew cask install is disabled! Use brew install [--cask] instead. In addition, "brew install caskroom/cask/perforce" step triggers an error that says: Error: caskroom/cask was moved. Tap homebrew/cask instead. Attempt to see if blindly following the suggestion in these error messages gets us into a better shape. Signed-off-by: Junio C Hamano

ci: avoid `set-env` construct in print-test-failures.sh

2020-11-17T20:12:30Z

Imitating cac42e47 (ci: avoid using the deprecated `set-env` construct, 2020-11-07), avoid deprecated ::set-env and use the recommended alternative instead in print-test-failures.sh Helped-by: Johannes Schindelin 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

Merge branch 'bc/sha-256-part-3'

2020-08-12T01:04:11Z

The final leg of SHA-256 transition. * bc/sha-256-part-3: (39 commits) t: remove test_oid_init in tests docs: add documentation for extensions.objectFormat ci: run tests with SHA-256 t: make SHA1 prerequisite depend on default hash t: allow testing different hash algorithms via environment t: add test_oid option to select hash algorithm repository: enable SHA-256 support by default setup: add support for reading extensions.objectformat bundle: add new version for use with SHA-256 builtin/verify-pack: implement an --object-format option http-fetch: set up git directory before parsing pack hashes t0410: mark test with SHA1 prerequisite t5308: make test work with SHA-256 t9700: make hash size independent t9500: ensure that algorithm info is preserved in config t9350: make hash size independent t9301: make hash size independent t9300: use $ZERO_OID instead of hard-coded object ID t9300: abstract away SHA-1-specific constants t8011: make hash size independent ...

ci: run tests with SHA-256

2020-07-30T16:16:49Z

Now that we have Git supporting SHA-256, we'd like to make sure that we don't regress that state. Unfortunately, it's easy to do so, so to help, let's add code to run one of our CI jobs with SHA-256 as the default hash. This will help us detect any problems that may occur. We pick the linux-clang job because it's relatively fast and the linux-gcc job already runs the testsuite twice. We want our tests to run as fast as possible, so we wouldn't want to add a third run to the linux-gcc job. To make sure we properly exercise the code, let's run the tests in the default mode (SHA-1) first and then run a second time with SHA-256. We explicitly specify SHA-1 for the first run so that if we change the default in the future, we make sure to test both cases. Signed-off-by: brian m. carlson Reviewed-by: Eric Sunshine 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

Merge branch 'jk/ci-only-on-selected-branches'

2020-05-29T22:12:19Z

Dev support. * jk/ci-only-on-selected-branches: ci/config: correct instruction for CI preferences

ci/config: correct instruction for CI preferences

2020-05-18T17:18:34Z

From e76eec3554 (ci: allow per-branch config for GitHub Actions, 2020-05-07), we started to allow contributors decide which branch they want to build with GitHub Actions by checking for a file named "ci/config/allow-ref". In order to assist those contributors, we provided a sample in "ci/config/allow-refs.sample", and instructed them to drop the ".sample", then commit that file to their repository. We've misspelt the filename in that change. Let's fix the spelling. While we're at it, also instruct our contributors introduce that new file to Git before commit, in case of they've never told Git before. Signed-off-by: Jeff King Signed-off-by: Đoàn Trần Công Danh 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