f62abd00db
When creating an action signature (e.g. for a commit author and committer) read the following environment variables that can override the configuration options: * `GIT_AUTHOR_NAME` is the human-readable name in the "author" field. * `GIT_AUTHOR_EMAIL` is the email for the "author" field. * `GIT_AUTHOR_DATE` is the timestamp used for the "author" field. * `GIT_COMMITTER_NAME` sets the human name for the "committer" field. * `GIT_COMMITTER_EMAIL` is the email address for the "committer" field. * `GIT_COMMITTER_DATE` is used for the timestamp in the "committer" field. * `EMAIL` is the fallback email address in case the user.email configuration value isn't set. If this isn't set, Git falls back to the system user and host names. This is taken from the git documentation chapter "10.8 Environment Variables": https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables This PR adds support for reading these environment variables by adding two new functions `git_signature_default_author` and `git_signature_default_committer` and deprecates the `git_signature_default` function. Fixes: https://github.com/libgit2/libgit2/issues/3751 Prior work: * https://github.com/libgit2/libgit2/pull/4409 * https://github.com/libgit2/libgit2/pull/5479 * https://github.com/libgit2/libgit2/pull/6290
libgit2 tests
These are the unit and integration tests for the libgit2 projects.
benchmarksThese are benchmark tests that excercise the CLI.clar
This is clar the common test framework.headertest
This is a simple project that ensures that our public headers are compatible with extremely strict compilation options.libgit2
These tests exercise the core git functionality in libgit2 itself.resources
These are the resources for the tests, including files and git repositories.util
These are tests of the common utility library.
Writing tests for libgit2
libgit2 uses the clar test framework, a C testing framework.
The best resources for learning clar are clar itself and the existing tests within libgit2. In general:
-
If you place a
.cfile into a test directory, it is eligible to contain test cases. -
The function name for your test is important; test function names begin with
test_, followed by the folder path (underscore separated), two underscores as a delimiter, then the test name. For example, a filemerge/analysis.cmay contain a testuptodate:void test_merge_analysis__uptodate(void) { ... } -
You can run an individual test by passing
-sto the test runner. Tests are referred to by their function names; for example, the functiontest_merge_analysis__uptodateis referred to asmerge::analysis::uptodate. To run only that function you can use the-soption on the test runner:libgit2_tests -smerge::analysis::uptodate
Memory leak checking
These are automatically run as part of CI, but if you want to check locally:
Linux
Uses valgrind:
$ cmake -DBUILD_TESTS=ON -DVALGRIND=ON ..
$ cmake --build .
$ valgrind --leak-check=full --show-reachable=yes --num-callers=50 --suppressions=../libgit2_tests.supp \
./libgit2_tests
macOS
Uses leaks, which requires XCode installed:
$ MallocStackLogging=1 MallocScribble=1 MallocLogFile=/dev/null CLAR_AT_EXIT="leaks -quiet \$PPID" \
./libgit2_tests
Windows
Build with the WIN32_LEAKCHECK option:
$ cmake -DBUILD_TESTS=ON -DWIN32_LEAKCHECK=ON ..
$ cmake --build .
$ ./libgit2_tests