git/ci, branch v2.36.2

Merge branch 'cb/ci-make-p4-optional' into maint

2022-06-08T21:27:51Z

macOS CI jobs have been occasionally flaky due to tentative version skew between perforce and the homebrew packager. Instead of failing the whole CI job, just let it skip the p4 tests when this happens. source: <20220512223940.238367-1-gitster@pobox.com> * cb/ci-make-p4-optional: ci: use https, not http to download binaries from perforce.com ci: reintroduce prevention from perforce being quarantined in macOS ci: avoid brew for installing perforce ci: make failure to find perforce more user friendly

ci: use https, not http to download binaries from perforce.com

2022-05-12T22:43:08Z

Since 522354d70f4 (Add Travis CI support, 2015-11-27) the CI has used http://filehost.perforce.com/perforce/ to download binaries from filehost.perforce.com, they were then moved to this script in 657343a602e (travis-ci: move Travis CI code into dedicated scripts, 2017-09-10). Let's use https instead for good measure. I don't think we need to worry about the DNS or network between the GitHub CI and perforce.com being MitM'd, but using https gives us extra validation of the payload at least, and is one less thing to worry about when checking where else we rely on non-TLS'd http connections. Also, use the same download site at perforce.com for Linux and macOS tarballs for consistency. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Carlo Marcelo Arenas Belón Signed-off-by: Junio C Hamano

ci: reintroduce prevention from perforce being quarantined in macOS

2022-05-12T22:43:08Z

5ed9fc3fc86 (ci: prevent `perforce` from being quarantined, 2020-02-27) introduces this prevention for brew, but brew has been removed in a previous commit, so reintroduce an equivalent option to avoid a possible regression. This doesn't affect github actions (as configure now) and is therefore done silently to avoid any possible scary irrelevant messages. Signed-off-by: Carlo Marcelo Arenas Belón Signed-off-by: Junio C Hamano

ci: avoid brew for installing perforce

2022-05-12T22:43:07Z

Perfoce's cask in brew is meant[1] to be used only by humans, so replace its use from the CI with a scripted binary download which is less likely to fail, as it is done in Linux. Kept the logic together so it will be less likely to break when moved around as on the fly code changes in this area are settled, at which point it will also feasable to ammend it to avoid some of the hardcoded values by using similar variables to the ones Linux does. In that same line, a POSIX sh syntax is used instead of the similar one used in Linux in preparation for an unrelated future change that might change the shell currently configured for it. This change reintroduces the risk that the installed binaries might not work because of being quarantined that was fixed with 5ed9fc3fc86 (ci: prevent `perforce` from being quarantined, 2020-02-27) but fixing that now was also punted for simplicity and since the affected cloud provider is scheduled to be retired with an on the fly change, but should be addressed if that other change is not integrated further. The discussion on the need to keep 2 radically different versions of the binaries to be tested with Linux vs macOS or how to upgrade to newer versions now that brew won't do that automatically for us has been punted for now as well. On that line the now obsolete comment about it in lib.sh was originally being updated by this change but created conflicts as it is moved around by other on the fly changes, so will be addressed independently as well. [1] https://github.com/Homebrew/homebrew-cask/pull/122347#discussion_r856026584 Signed-off-by: Carlo Marcelo Arenas Belón Signed-off-by: Junio C Hamano

ci: make failure to find perforce more user friendly

2022-05-12T22:43:07Z

In preparation for a future change that will make perforce installation optional in macOS, make sure that the check for it is done without triggering scary looking errors and add a user friendly message instead. All other existing uses of 'type ' in our shell scripts that check the availability of a command send both standard output and error stream to /dev/null to squelch " not found" diagnostic output, but this script left the standard error stream shown. Redirect it just like everybody else to squelch this error message that we fully expect to see. Helped-by: Eric Sunshine Signed-off-by: Carlo Marcelo Arenas Belón Signed-off-by: Junio C Hamano

CI: select CC based on CC_PACKAGE (again)

2022-04-22T18:28:17Z

Fix a regression in 707d2f2fe86 (CI: use "$runs_on_pool", not "$jobname" to select packages & config, 2021-11-23). In that commit I changed CC=gcc from CC=gcc-9, but on OSX the "gcc" in $PATH points to clang, we need to use gcc-9 instead. Likewise for the linux-gcc job CC=gcc-8 was changed to the implicit CC=gcc, which would select GCC 9.4.0 instead of GCC 8.4.0. Furthermore in 25715419bf4 (CI: don't run "make test" twice in one job, 2021-11-23) when the "linux-TEST-vars" job was split off from "linux-gcc" the "cc_package: gcc-8" line was copied along with it, so its "cc_package" line wasn't working as intended either. As a table, this is what's changed by this commit, i.e. it only affects the linux-gcc, linux-TEST-vars and osx-gcc jobs: |-------------------+-----------+-------------------+-------+-------| | jobname | vector.cc | vector.cc_package | old | new | |-------------------+-----------+-------------------+-------+-------| | linux-clang | clang | - | clang | clang | | linux-sha256 | clang | - | clang | clang | | linux-gcc | gcc | gcc-8 | gcc | gcc-8 | | osx-clang | clang | - | clang | clang | | osx-gcc | gcc | gcc-9 | clang | gcc-9 | | linux-gcc-default | gcc | - | gcc | gcc | | linux-TEST-vars | gcc | gcc-8 | gcc | gcc-8 | |-------------------+-----------+-------------------+-------+-------| Reported-by: Carlo Arenas Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

compat: auto-detect if zlib has uncompress2()

2022-01-26T17:05:55Z

We have a copy of uncompress2() implementation in compat/ so that we can build with an older version of zlib that lack the function, and the build procedure selects if it is used via the NO_UNCOMPRESS2 $(MAKE) variable. This is yet another "annoying" knob the porters need to tweak on platforms that are not common enough to have the default set in the config.mak.uname file. Attempt to instead ask the system header to decide if we need the compatibility implementation. This is a deviation from the way we have been handling the "compatiblity" features so far, and if it can be done cleanly enough, it could work as a model for features that need compatibility definition we discover in the future. With that goal in mind, avoid expedient but ugly hacks, like shoving the code that is conditionally compiled into an unrelated .c file, which may not work in future cases---instead, take an approach that uses a file that is independently compiled and stands on its own. Compile and link compat/zlib-uncompress2.c file unconditionally, but conditionally hide the implementation behind #if/#endif when zlib version is 1.2.9 or newer, and unconditionally archive the resulting object file in the libgit.a to be picked up by the linker. There are a few things to note in the shape of the code base after this change: - We no longer use NO_UNCOMPRESS2 knob; if the system header claims a version that is more cent than the library actually is, this would break, but it is easy to add it back when we find such a system. - The object file compat/zlib-uncompress2.o is always compiled and archived in libgit.a, just like a few other compat/ object files already are. - The inclusion of is done in ; we used to do so from which includes as the first thing it does, so from the *.c codes, there is no practical change. - Until objects in libgit.a that is already used gains a reference to the function, the reftable code will be the only one that wants it, so libgit.a on the linker command line needs to appear once more at the end to satisify the mutual dependency. - Beat found a trick used by OpenSSL to avoid making the conditionally-compiled object truly empty (apparently because they had to deal with compilers that do not want to see an effectively empty input file). Our compat/zlib-uncompress2.c file borrows the same trick for portabilty. Signed-off-by: Ævar Arnfjörð Bjarmason Helped-by: Beat Bolli Signed-off-by: Junio C Hamano

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 'hn/reftable'

2021-12-15T17:39:45Z

The "reftable" backend for the refs API, without integrating into the refs subsystem, has been added. * hn/reftable: Add "test-tool dump-reftable" command. reftable: add dump utility reftable: implement stack, a mutable database of reftable files. reftable: implement refname validation reftable: add merged table view reftable: add a heap-based priority queue for reftable records reftable: reftable file level tests reftable: read reftable files reftable: generic interface to tables reftable: write reftable files reftable: a generic binary tree implementation reftable: reading/writing blocks Provide zlib's uncompress2 from compat/zlib-compat.c reftable: (de)serialization for the polymorphic record type. reftable: add blocksource, an abstraction for random access reads reftable: utility functions reftable: add error related functionality reftable: add LICENSE hash.h: provide constants for the hash IDs

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