The GitHub Actions CI jobs have been updated to fix breakages caused
by the move to Ubuntu 26.04 runner images, including using 'apt-get'
instead of 'apt' for stable CLI output, elevating permissions when
replacing system binaries, and temporarily pinning the 'linux32' job
to Ubuntu 24.04 to avoid seccomp-related networking failures.
* hn/ci-ubuntu-26.04-fixes:
ci: pin linux32 to ubuntu-24.04 to restore networking
install-dependencies: work around a permission problem
ci: use apt-get in the linux32 job
The test environment setup in the CI scripts has been consolidated and
deduplicated to remove redundancies and simplify test flag management.
* ps/ci-consolidate-test-variables:
ci: don't override initial branch name in testbed job
ci/lib: add another NO_RUST build using glibc
t: honor default ref storage format
ci/lib: merge switches for specific job names
ci/lib: deduplicate test variables by pattern matching
ci/lib: always set GIT_TEST_USE_SET_E on Linux jobs
ci: consolidate setup of test environment
The CI scripts have been updated to fail the build immediately when
optional dependencies like Perforce, Git-LFS, or JGit fail to
install, instead of silently skipping their tests..
* hn/ci-fail-on-missing-deps:
ci: fail the build if perforce, git-lfs, or JGit fail to install
ci: drop quarantine removal for macos perforce binaries
The testbed job overrides GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME to
"master". This is rather pointless nowadays though, as we already
configure the initial branch name to either "main" or "master" depending
on the "WITH_BREAKING_CHANGES" toggle.
Drop this override.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With 32d5b90590 (Enable Rust by default, 2026-04-09) we have enabled
Rust by default. As part of that change we also lost test coverage of
non-Rust builds, as the only platform where we still exercise without
Rust is on Alpine Linux with musl libc.
Adapt the "linux-asan-ubsan" job to disable Rust to restore some of that
coverage. This job was chosen because we also get more bang for the buck
checking for memory safety issues in a job where we use C instead of
Rust, as Rust is supposedly memory-safe by itself already.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the preceding consolidations of test variables we now pointlessly
have three switches over "$jobname". Merge them into a single switch.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have a couple of test variables that we set in multiple different
jobs. These jobs always have specific identifiers in their names and can
thus easily be told apart from the other jobs.
Use this fact to deduplicate the setup of those test variables by
pattern matching for those identifiers.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The GIT_TEST_USE_SET_E test variable determines whether we run our test
suite with `set -e` enabled or not. This works on all of our supported
Linux distributions, but it doesn't work on macOS because the version of
Bash used there is rather old and thus has some differences in
behaviour.
We currently set that variable for a bunch of distros explicitly, which
is tedious to keep up-to-date. For example, our "linux32" job does not
enable the test variable even though it could. Adapt the script to
instead set it on any Linux distribution.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The setup of our test environment is split up across "ci/lib.sh" and
"ci/run-build-and-tests.sh". It is not exactly obvious why that split
even exists, and because of the split you have to know about both of the
locations to be able to figure out the specific environment that applies
to a specific job.
Consolidate the setup into "ci/lib.sh". Note that this is a pure move
for now that results in some awkward duplication. This duplication will
be cleaned up in subsequent commits.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A failed install of perforce, git-lfs, or JGit was silently
tolerated. The corresponding tests would just skip and the build
stayed green, so a broken download could go unnoticed indefinitely.
Fail the build immediately instead on the platforms that install
these tools. The presence checks and warnings at the end of the
script are gone too, since we already know by then that everything
installed or the build wouldn't have gotten this far.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The xattr -d call that strips com.apple.quarantine from the macOS
perforce binaries has been doing nothing for years, and can simply
go.
5ed9fc3fc8 (ci: prevent `perforce` from being quarantined,
2020-02-27) added that call to stop p4d -V from hanging on a GUI
confirmation dialog that never comes on a CI box, back when perforce
was installed via Homebrew's --no-quarantine cask flag. When
49af448197 (ci: reintroduce prevention from perforce being
quarantined in macOS, 2022-05-12) replaced that with a plain wget
and tar download, it kept the xattr -d call as a precaution, while
noting that it already does nothing on GitHub Actions.
A file downloaded with wget never gets com.apple.quarantine set in
the first place, only Safari, Finder, and AirDrop apply that
attribute through the LaunchServices quarantine API. The same holds
on GitLab CI's macOS runners, so the call has been a silent no-op
everywhere since 2022.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Various CI jobs have been updated to use modern OS images, drop dead
code, and remove redundant jobs. Support for Python 2 in CI has been
removed, and the linux-TEST-vars job has been renamed to
linux-feature-testbed.
* ps/ci-housekeeping-and-modernizations:
ci: improve reftable test coverage
ci: drop now-dead Python 2 coverage
ci: switch away from EOL'd Ubuntu version in linux-feature-testbed
ci: rename linux-TEST-vars job
ci: switch away from unsupported i386/ubuntu image
ci: drop unused "linux-clang" logic
ci: fix "fedora-breaking-changes-meson" job
t5004: fix test creating an archive with large objects under SHA256
CI on GitHub Actions gets a better annotation experience. Leak test
scripts are stopped at their first failure with --immediate to
prevent flooding the log, and failures are correctly annotated with
their file and line number.
* hn/ci-leak-sanitizer-annotations:
ci: point test failures and fixed known breakages at their file and line
ci: annotate leaks and stop a leak-sanitizer script at its first failure
CI resource exhaustion during test runs on GitHub Actions has been
mitigated by switching a comparison of a huge output to use a binary
comparison, and by capping the parallel jobs on Linux to the number
of available CPUs.
* td/ci-large-test-resources:
ci: use twice the CPU count on both providers
t4205: compare huge output without diff
The build configurations for Meson have been optimized to avoid
recompiling HTTP sources multiple times and to utilize precompiled
headers for test-helpers and unit tests, reducing clean build times.
Additionally, the shell completion tests and GitLab CI MSVC runner
jobs have been fixed.
* ps/meson-improvements:
gitlab-ci: fix hanging MSVC jobs
meson: update wrappers
meson: fix outdated completion helpers
meson: use precompiled headers for unit tests
meson: use precompiled headers for our test-helper
meson: don't recompile git-remote-http(1) multiple times for tests
meson: avoid recompiling HTTP sources several times
The "linux-reftable" job exercises Git with reftables as its default
backend. But this job is arguably redundant because we already have the
"linux-reftable-leaks" job that exercises reftables with the leak
sanitizer enabled, and it is unlikely that we will catch any extra bugs
with the leak sanitizer disabled.
One may thus be triggered to just drop the "linux-reftable" job in favor
of the leak-checking variant. But the latter disables a couple of other
tests that exercise git-p4, git-svn and other tools. Those tools may not
be an essential part of Git nowadays, but I don't quite feel comfortable
with reducing test coverage.
Instead, adapt the job to run reftables together with SHA256. which is
an area that we don't have test coverage for.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the preceding commit we've dropped the last job that still used
Ubuntu 20.04. We still had some conditional logic for that specific
image that made us use Python 2 instead of Python 3, but this is dead
code now.
We could of course exercise Python 2 in any of our other CI jobs. But it
reached end of life in 2020 already, and none of the distros that we use
have it packaged anymore. Furthermore, it seems like the world has
finally adapted to Python 3. So it doesn't feel all that useful to still
exercise it.
Drop the logic and instead use Python 3 unconditionally.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "linux-TEST-vars" job exercises Git with a bunch of non-default
options enabled. The name of that job makes you want to cry though due
to the weird upper-casing and because it doesn't really tell you what it
even intends to do.
Rename the job to "linux-feature-testbed" instead.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The linux32 job is used to exercise Git on a 32 bit platform. That job
uses i386/ubuntu:20.04 though, and that version of Ubuntu is end of life
nowadays. Furthermore, Ubuntu 20.04 is the last release that has support
for 32 bit, so we cannot upgrade the image to a later version, either.
Switch the job over to use i386/debian instead. Note that starting with
Debian 13, support for i386 has been reduced [1]. But Debian still
releases 32 bit Docker images for the latest release nowadays, so we
will have coverage until at least 2030.
[1]: https://www.debian.org/releases/trixie/release-notes/issues.en.html#i386-reduced-support
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In d88d727143 (ci: drop linux-clang job, 2023-06-01) we have dropped the
"linux-clang" job because another job already uses Clang anyway. But we
forgot to also drop the logic in "ci/run-build-and-tests.sh", so we now
have some unused logic in there.
Drop it.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "fedora-breaking-changes-meson" job exercises Git with breaking
changes enabled on Fedora with Meson. There's a typo in our CI scripts
though, which has the effect that the build does not enable breaking
changes by accident.
Fix the typo.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The Windows GitLab CI job has been updated to provision and use the
GCC-targeting Rust toolchain for MinGW builds, fixing job failures
caused by incomplete Rust setup and missing linker support.
* js/gitlab-ci-windows-rust:
ci(gitlab,windows): provide GNU Rust's host-linker support
ci(gitlab,windows): fix Rust setup for GitLab's MinGW build
ci(gitlab,windows): preserve exclusions during dependency setup
ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
A leak is only discovered once, at the end of a whole script, well
after every test has already reported ok, and it gets no annotation at
all, so a leak-sanitizer job's only visible failure is:
Process completed with exit code 1.
Give a leak its own annotation, naming the script it turned up in, the
exact line isn't known, only which script:
memory leak logged in t1060 (t1060-object-corruption.sh)
Put the sanitizer report in a log group next to it, so it stays
visible.
Once a script has one leak, it keeps running: the sanitizer log
directory is never cleared between tests, so every later test in the
same script sees the same leftover log entries and also reports "not
ok", burying the one real failure in copies of itself. Stop a
leak-sanitizer script at its first failure with --immediate instead.
A failing test already gets its own annotation once its script
finishes, but --immediate exits as soon as that test fails, before
reaching the code that writes it. Write the annotation first, so
turning on --immediate here does not silently drop it.
Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The CI script has been updated to check for one-indexed slice numbers
when deciding to run unit tests on Windows, mirroring the behaviour in
the modern GitHub and GitLab workflows.
* kn/ci-unit-tests-on-windows-fix:
ci: fix unit tests not running on windows
The terminology regarding reference storage formats has been unified
across command-line options, environment variables, configuration
variables, and source code, standardizing on the phrase "ref storage
format" (e.g., `--ref-storage-format`, `'GIT_REF_STORAGE_FORMAT'`).
Additionally, the `--ref-storage-format` option has been updated to
accept payloads in the form `<format>://<payload>`.
* ps/ref-storage-format:
setup: allow "--ref-storage-format=" to specify a payload
setup: rename "init.defaultRefFormat" to "init.defaultRefStorageFormat"
t: rename GIT_TEST_DEFAULT_REF_FORMAT
setup: rename ref storage format environment variables
setup: refactor how we configure the ref storage format
refs: expose function to parse reference URIs
help: rename "default-ref-format" to "default-ref-storage-format"
builtin/rev-parse: rename "--show-ref-format" to "--show-ref-storage-format"
builtin/submodule: rename "--ref-format=" to "--ref-storage-format="
builtin/refs: rename "--ref-format=" to "--ref-storage-format="
builtin/clone: rename "--ref-format=" to "--ref-storage-format="
builtin/init: rename "--ref-format=" to "--ref-storage-format="
parse-options: allow for hidden aliases
GitHub Actions sets JOBS to ten regardless of runner size, while
GitLab CI uses the detected CPU count. Use twice the CPU count for
Make and prove on both providers, doubling GitLab's job count.
Five GitHub Actions attempts per policy, with the long tests enabled,
gave these sums of per-job median successful build/test-step times
(minutes; four or five samples per job) [1-3]:
Fixed 10 CPU count 2x CPU count
Linux Make 278.9 273.9 259.9
macOS Make 94.5 119.1 99.8
Windows Make 102.2 103.8 100.8
Workflow overhead is excluded; Windows runner images varied.
Use twice the CPU count to scale concurrency with runner size while
avoiding the larger macOS slowdown observed with one job per CPU.
Compared with ten jobs, this trades a lower Linux total for a higher
macOS total.
Keep GitLab's Linux and Windows CPU queries. On macOS, use the native
sysctl command on both providers so CPU detection does not depend on
GNU coreutils.
Link: https://github.com/tamird/git/actions/runs/36070869894/attempts/1 [1]
Link: https://github.com/tamird/git/actions/runs/36070867524/attempts/1 [2]
Link: https://github.com/tamird/git/actions/runs/36070867647/attempts/1 [3]
Assisted-by: LLM
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Creating .git/info/exclude as a file with `New-Item` and `-Force`
truncates existing contents.
When install-dependencies.ps1 follows install-sdk.ps1, this discards
the latter's /git-sdk exclusion and causes ci/lib.sh to reject SDK
files as unignored build artifacts.
Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The minimal Git for Windows SDK already supplies Git and GCC. The MinGW
Makefile build needs the Rust toolchain that targets GCC (as opposed to
the more common MSVC one), not another Git installation or Meson.
Prepare the `install-dependencies.ps1` script to be able to install the
GCC-targeting Rust toolchain.
Assisted-by: GPT-6
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 3141df7ec4 (ci: don't skip smallest test slice in GitLab,
2026-02-19) both our CI workflows at GitLab and GitHub use one-indexed
slices to run windows tests. Modify the check for running unit tests on
Windows to also be one-indexed as otherwise, the unit tests are never
run.
Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Starting with GitLab Runner 19.x, the runner executes `git credential
reject` in its cleanup stage. This has bad interactions with our build
environment because we install our own version of PortableGit, and the
runner picks up that version of Git. The consequence is that we invoke
PortableGit's default credential manager, which is Git Credential
Manager for Windows. GCM then tries to use Windows Credential Manager,
but it cannot and thus the job hangs in its cleanup phase forever.
Fix this hang by unsetting the credential helper after installing
PortableGit. This means that `git credential reject` becomes a no-op,
and thus the cleanup succeeds again.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update Windows CI build to support Rust.
* js/rust-in-windows-ci:
ci(windows): build with Rust
rust: pick a GCC-compatible Cargo target under MSYS2/MinGW
The CI script to install dependencies for the documentation build
has been updated to install asciidoctor directly via the system
package manager instead of pinning to an older version via gem.
Additionally, an obsolete variable used for retired Azure Pipelines
environments has been removed.
* jk/ci-use-system-asciidoctor:
ci: use system asciidoctor
The Windows runners used by Git's GitHub workflow's `windows-build` job
ship `rustup` plus a `*-pc-windows-msvc` default toolchain (see
https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md
and
https://github.com/actions/partner-runner-images/blob/main/images/arm-windows-11-image.md),
but no precompiled `std` for `*-pc-windows-gnu` or
`*-pc-windows-gnullvm`. With the Makefile now picking a GCC-compatible
target triple based on `$(MSYSTEM)`, the build step needs that
precompiled `std` to be installed before invoking `make`, otherwise
`cargo build --target <triple>` fails to find a usable `std` for the
chosen target.
Add a step between the SDK setup and the `make` invocation that selects
the matching triple from `$MSYSTEM` (which
`git-for-windows/setup-git-for-windows-sdk` exports for every subsequent
step) and runs `rustup target add` for it. The mapping mirrors what
`config.mak.uname` derives from `$(MSYSTEM)` and `$(HOST_CPU)`, just
enumerated explicitly here since CI has direct knowledge of which MSYS2
subsystems the matrix actually exercises (`CLANGARM64` for the ARM64
runner, `MINGW64` for the x86_64 runner). Technically, we only need to
handle MINGW64 at present, but the switch to UCRT64 is imminent, and the
other case arms serve as a very fine documentation of what people should
do for other MSYSTEM values.
For a `staticlib` crate-type `cargo build` does not invoke an external
linker, so no further toolchain components (e.g. the `gnullvm` LLVM
linker) need to be installed; `rustup target add` alone is sufficient.
Assisted-by: Claude Opus 4.7
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our CI Documentation builds have pinned asciidoctor since 615a6c37e1
(ci: stick with Asciidoctor v1.5.8 for now, 2019-03-29). Back then a few
changes were needed to build with the then-new v2.0.0.
We've since made those changes, in f6461b82b9 (Documentation: fix build
with Asciidoctor 2, 2019-09-15) and other commits. So it is not only
safe to use newer versions of asciidoctor, but preferable: it's what
people are likely to use for actually building the documentation in
practice!
I don't think there's any need to pin to a specific version. We can just
use what ships in our Ubuntu image, which should give us an arbitrary
representative version (and if it changes and something breaks, we'd
want to know).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The CI script to install dependencies for the documentation build
has been updated to install asciidoctor directly via the system
package manager instead of pinning to an older version via gem.
Additionally, an obsolete variable used for retired Azure Pipelines
environments has been removed.
* jk/ci-use-system-asciidoctor:
ci: drop ALREADY_HAVE_ASCIIDOCTOR variable
ci: fix missing Ruby dependency in "documentation" job
Our install-dependencies script avoids installing asciidoctor if the
CI environment claims to have it already. But the only environment which
made use of this was Azure Pipelines, which went away in 6081d3898f (ci:
retire the Azure Pipelines definition, 2020-04-11). So this conditional
was effectively doing nothing. Let's clean it up.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our "documentation" job has recently stopped working with the following
error:
+ sudo gem install --version 1.5.8 asciidoctor
+ gem install --version 1.5.8 asciidoctor
./ci/install-dependencies.sh: 23: gem: not found
The root cause of this is that we never explicitly install Ruby, and
consequently gem(1) isn't explicitly pulled in, either. This used to
work alright because we transitively pulled in Ruby via asciidoc. But
due to an update it seems that we stopped pulling in the transitive
dependency, and consequently we don't have gem(1) available anymore.
Fix this by explicitly installing Ruby.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the same reasoning as for all the other environment variables,
rename the GIT_TEST_DEFAULT_REF_FORMAT environment variable to
GIT_TEST_DEFAULT_REF_STORAGE_FORMAT.
Note that in this case, the old name is not retained for backwards
compatibility as this is only running in the context of tests anyway.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'reftable' code has been hardened against corrupted tables by
fixing out-of-bounds writes, out-of-bounds reads, and abort calls
during parsing.
* ps/reftable-hardening:
reftable/table: fix OOB read on truncated table
reftable/table: fix NULL pointer access when seeking to bogus offsets
reftable/block: fix OOB read with bogus restart offset
reftable/block: fix use of uninitialized memory when binsearch fails
reftable/block: fix OOB read with bogus restart count
reftable/block: fix OOB read with bogus block size
reftable/block: fix OOB write with bogus inflated log size
t/unit-tests: introduce test helper to write reftable blocks
reftable/record: don't abort when decoding invalid ref value type
reftable/basics: fix OOB read on binary search of empty range
oss-fuzz: add fuzzer for parsing reftables
meson: support building fuzzers with libFuzzer
Starting with 7a094d68a2 (ci: run expensive tests on push builds to
integration branches, 2026-05-08) we run expensive tests in our CI for
certain events. So far, this has only been wired up for GitHub Workflows
though, which creates a test gap for GitLab CI.
Plug this gap by also making this work for the latter.
Note that these tests cannot be run on the Windows runners, as they only
have 7.5GB of RAM. This is insufficient for some of the EXPENSIVE tests,
so we explicitly disable "GIT_TEST_LONG" on these jobs.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's currently hard to explicitly disable GIT_TEST_LONG by setting it to
`false`. Fix this by using `test_bool_env` instead.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a new fuzzer that exercises our parsing of reftables. Fallout from
this fuzzer will be fixed over subsequent commits.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Wean the Windows builds in GitLab CI procedure away from
(unfortunately unreliable) Chocolatey to install dependencies.
* ps/gitlab-ci-windows:
gitlab-ci: migrate Windows builds away from Chocolatey
The Windows builds in GitLab CI use Chocolatey to install dependencies.
Unfortunately, Chocolatey seems to be very unreliable, which causes the
jobs to fail very regularly. This is a limitation that seems to be
somewhat known [1]:
As an organization, you want 100% reliability (or at least that
potential), and you may want full trust and control as well. This is
something you can get with internally hosted packages, and you are
unlikely to achieve from use of the Community Package Repository.
So using the Community Package Repository is kind of discouraged in case
one wants reliability. We _do_ want reliability though, and we cannot
easily switch to an enterprise license to fix this issue.
Introduce a new script that downloads and installs dependencies
directly. This has a couple of benefits:
- We can drop our dependency on Chocolatey completely, thus improving
reliability.
- We can easily cache the installers.
- We get direct control over the exact versions we install.
- Installing dependencies is sped up from roundabout 3 minutes to 1
minute.
[1]: https://docs.chocolatey.org/en-us/community-repository/community-packages-disclaimer/#summary
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The GitLab CI definitions are missing jobs for AlmaLinux and Debian,
both of which exist in GitHub Workflows. Plug this gap.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Enable expensive tests to catch topics that may cause breakages on
integration branches closer to their origin in the contributor PR
builds.
* jc/ci-enable-expensive:
ci: enable EXPENSIVE for contributor builds
Update code paths that assumed "unsigned long" was long enough for
"size_t".
* js/objects-larger-than-4gb-on-windows:
ci: run expensive tests on push builds to integration branches
t5608: mark >4GB tests as EXPENSIVE
test-tool synthesize: add precomputed SHA-256 pack for 4 GiB + 1
test-tool synthesize: precompute pack for 4 GiB + 1
test-tool synthesize: use the unsafe hash for speed
t5608: add regression test for >4GB object clone
test-tool: add a helper to synthesize large packfiles
delta, packfile: use size_t for delta header sizes
odb, packfile: use size_t for streaming object sizes
git-zlib: handle data streams larger than 4GB
index-pack, unpack-objects: use size_t for object size
The test suite harness and many individual test scripts have been
updated to work correctly when 'set -e' is in effect, which helps
detect misspelled test commands.
* ps/test-set-e-clean:
t: detect errors outside of test cases
t9902: fix use of `read` with `set -e`
t6002: fix use of `expr` with `set -e`
t1301: don't fail in case setfacl(1) doesn't exist or fails
t0008: silence error in subshell when using `grep -v`
t: prepare `test_when_finished ()`/`test_atexit()` for `set -e`
t: prepare execution of potentially failing commands for `set -e`
t: prepare conditional test execution for `set -e`
t: prepare `git config --unset` calls for `set -e`
t: prepare `stop_git_daemon ()` for `set -e`
t: prepare `test_must_fail ()` for `set -e`
t: prepare `test_match_signal ()` calls for `set -e`
Junio C Hamano