Get tags for tests from original repo as fallback

EliahKagan · EliahKagan · commit b98f15e46a7d · 2023-10-03T15:40:40.000-04:00
This extends the init script so it tries harder to get version
tags:

- As before, locally, "git fetch --all --tags" is always run. (This
  also fetches other objects, and the developer experience would be
  undesirably inconsistent if that were only sometimes done.)

- On CI, run it if version tags are absent. The criterion followed
  here and in subsequent steps is that if any existing tag starts
  with a digit, or with the letter v followed by a digit, we regard
  version tags to be present. This is to balance the benefit of
  getting the tags (to make the tests work) against the risk of
  creating a very confusing situation in clones of forks that
  publish packages or otherwise use their own separate versioning
  scheme (especially if those tags later ended up being pushed).

- Both locally and on CI, after that, if version tags are absent,
  try to copy them from the original gitpython-developers/GitPython
  repo, without copying other tags or adding that repo as a remote.
  Copy only tags that start with a digit, since v+digit tags aren't
  currently used in this project (though forks may use them). This
  is a fallback option and it always displays a warning. If it
  fails, another message is issued for that. Unexpected failure to
  access the repo terminates the script with a failing exit status,
  but the absence of version tags in the fallback remote does not,
  so CI jobs can continue and reveal which tests fail as a result.

On GitHub Actions CI specifically, the Actions syntax for creating
a warning annotation on the workflow is used, but the warning is
still also written to stderr (as otherwise). GHA workflow
annotations don't support multi-line warnings, so the message is
adjusted into a single line where needed.
diff --git a/init-tests-after-clone.sh b/init-tests-after-clone.sh
@@ -2,11 +2,25 @@
 
 set -eu
 
+fallback_repo_for_tags='https://github.com/gitpython-developers/GitPython.git'
+
 ci() {
     # For now, check just these, as a false positive could lead to data loss.
     test -n "${TRAVIS-}" || test -n "${GITHUB_ACTIONS-}"
 }
 
+no_version_tags() {
+    test -z "$(git tag -l '[0-9]*' 'v[0-9]*')"
+}
+
+warn() {
+    printf '%s\n' "$@" >&2  # Warn in step output.
+
+    if test -n "${GITHUB_ACTIONS-}"; then
+        printf '::warning ::%s\n' "$*" >&2  # Annotate workflow.
+    fi
+}
+
 if ! ci; then
     printf 'This operation will destroy locally modified files. Continue ? [N/y]: ' >&2
     read -r answer
@@ -33,11 +47,27 @@ git reset --hard HEAD~1
 # Point the master branch where we started, so we test the correct code.
 git reset --hard __testing_point__
 
-# Do some setup that CI takes care of but that may not have been done locally.
+# The tests need submodules. (On CI, they would already have been checked out.)
 if ! ci; then
-    # The tests need some version tags. Try to get them even in forks.
+    git submodule update --init --recursive
+fi
+
+# The tests need some version tags. Try to get them even in forks. This fetch
+# gets other objects too, so for a consistent experience, always do it locally.
+if ! ci || no_version_tags; then
     git fetch --all --tags
+fi
 
-    # The tests need submodules, including a submodule with a submodule.
-    git submodule update --init --recursive
+# If we still have no version tags, try to get them from the original repo.
+if no_version_tags; then
+    warn 'No local or remote version tags found. Trying fallback remote:' \
+         "$fallback_repo_for_tags"
+
+    # git fetch supports * but not [], and --no-tags means no *other* tags, so...
+    printf 'refs/tags/%d*:refs/tags/%d*\n' 0 0 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 |
+        xargs git fetch --no-tags "$fallback_repo_for_tags"
+
+    if no_version_tags; then
+        warn 'No version tags found anywhere. Some tests will fail.'
+    fi
 fi
