The current release process is not documented in any way. As a result,
it's not obvious how releases should be done at all, like e.g. which
locations need adjusting.
To fix this, let's introduce a new script that shall from now on be used
to do all releases. As input it gets the tree that shall be released,
the repository in which to do the release, credentials to
authenticate against GitHub and the new version. E.g. executing the
following will create a new release v0.32:
$ ./script/release.py 0.32.0 --user pks-t --password ****
While the password may currently be your usual GitLab password, it's
recommended to use a personal access token intead.
The script will then perform the following steps:
1. Verify that "include/git2/version.h" matches the new version.
2. Verify that "docs/changelog.md" has a section for that new
version.
3. Extract the changelog entries for the current release from
"docs/changelog.md".
4. Generate two archives in "tar.gz" and "zip" format via "git
archive" from the tree passed by the user. If no tree was passed,
we will use "HEAD".
5. Create the GitHub release using the extracted changelog entries
as well as tag and name information derived from the version
passed by the used.
6. Upload both code archives to that release.
This should cover all steps required for a new release and thus ensures
that nothing is missing that shouldn't be.
valgrind will warn that OpenSSL will use undefined data in connect/read
when talking to certain other TLS stacks. Thankfully, this only seems
to occur when gcc is the compiler, so hopefully valgrind is just
misunderstanding an optimization. Regardless, suppress this warning.
On Ubuntu, the combination of libgcrypt and libssh2 is quite old and
known to contain memory leaks. We thus have several functions listed in
our suppressions file that are known to leak. Due to a recent update of
libssh2 or libgcrypt, there now are new memory leaks caused by
libssh2_session_handshake and libssh2_init that cause the CI to fail.
Add a new suppression to fix the issue.
Right now, we have an awful hack in our test CI setup that extracts the
test command from CTest's output and then prepends the leak checker.
This is dependent on non-machine-parseable output from CMake and also
breaks on various ocassions, like for example when we have spaces in the
current path or when the path contains backslashes. Both conditions may
easily be triggered on Win32 systems, and in fact they do break our
Azure Pipelines builds.
Remove the awful hack in favour of a new CMake build option
"USE_LEAK_CHECKER". If specifying e.g. "-DUSE_LEAK_CHECKER=valgrind",
then we will set up all tests to be run under valgrind. Like this, we
can again simply execute ctest without needing to rely on evil sourcery.
Coverity considers that anything that looks like assert() behaves like
it (ie. side-effects would be skipped on a NDEBUG build). As we have a
bunch of those in the test suite (128), this would ensure Coverity isn't
confused.
Simplify the names for the tests, removing the unnecessary
"libgit2-clar" prefix. Make "all" the new default test run, and include
the online tests by default (since HTTPS should always be enabled).
For the CI tests, create an offline-only test, then the various online
tests.
This adds a simple script for backporting pull requests to older
branches. It accepts as parameters a list of pull request numbers which
whose commits are to be cherry-picked. The identification of PRs
currently happens by using the commit message of the merge of the PR,
which should conform to the message "Merge pull request #<PR>".
While the heuristic works in practice, we could instead also use the
direct references from GitHub via "pull/#<PR>/head". This requires the
user to have all these references fetched, though, so we can just use
the current heuristic until we experience any issues with that.
Some tests shall be run against our own SSH server we spin up in Travis.
As those need to be run separate from our previous tests which run
against git-daemon, we have to do this in a separate step. Instead of
bundling all that knowledge in the CI script, move it into the test
build instructions by creating a new test target.
Right now, we test our credential callback code twice, once via SSH on
localhost and once via a non-existent GitHub repository. While the first
URL makes sense to be configurable, it does not make sense to hard-code
the non-existing repository, which requires us to call tests multiple
times. Instead, we can just inline the URL into another set of tests.
We support two types of passing credentials to the proxy, either via the
URL or explicitly by specifying user and password. We test these types
by modifying the proxy URL and executing the tests twice, which is
in fact unnecessary and requires us to maintain the list of environment
variables and test executions across multiple CI infrastructures.
To fix the situation, we can just always pass the host, port, user and
password to the tests. The tests can then assemble the complete URL
either with or without included credentials, allowing us to test both
cases in-process.
By default, CMake will not build our examples directory. As we do not
instruct either the MinGW or MSVC builds on AppVeyor to enable building
these examples, we cannot verify that those examples at least build on
Windows systems.
Fix that by passing `-DBUILD_EXAMPLES=ON` to AppVeyor's CMake
invocation.
Ubuntu trusty has a bug in curl when using NTLM credentials in a proxy,
dereferencing a null pointer and causing segmentation faults. Use a
custom-patched version of libcurl that avoids this issue.
Some tests of ours require to be running against an SSH server.
Currently, we simply run against the SSH server provided and started by
Travis itself. As our Linux tests run in a sudo-less environment, we
have no control over its configuration and startup/shutdown procedure.
While this has been no problem until now, it will become a problem as
soon as we migrate over to newer Precise images, as the SSH server does
not have any host keys set up. Luckily, we can simply set up our own
unpriviledged SSH server. This has the benefit of us being able to
modify its configuration even in a sudo-less environment.
This commit sets up the unpriviledged SSH server on port 2222.
The formulae provided by the homebrew/dupes tap are deprecated since at
least April 4, 2017, with formulae having been migrated to
homebrew/core.
Replace the deprecated reference to "homebrew/dupes/zlib" with only
"zlib".
When running a Coverity build, we have to provide an
authentication token in order to proof that we are actually
allowed to run analysis in the name of a certain project. As this
token should be secret, it is only set on the main repository, so
when we were requested to run the Coverity script on another
repository we do error out. But in fact we do also error out if
the Coverity analysis should _not_ be run if there is no
authentication token provided.
Fix the issue by only checking for the authentication token after
determining if analysis is indeed requested.
We used to only execute Coverity analysis on the 'development'
branch before commit 998f001 (Refine build limitation,
2014-01-15), which refined Coverity build limitations. While we
do not really use the 'development' branch anymore, it does
still make sense to only analyze a single branch, as otherwise
Coverity might get confused.
Re-establish the restriction such that we only analyze libgit2's
'master' branch. Also fix the message announcing why we do not
actually analyze a certain build.
