From 6adb4a39dcedd76bcd7037280dfb18b878f8c593 Mon Sep 17 00:00:00 2001 From: Eliah Kagan Date: Wed, 18 Oct 2023 06:40:40 -0400 Subject: [PATCH] Have init script clone submodules unconditionally Since 7110bf8 (in #1693), "git submodule update --init --recursive" was not run on CI, on the mistaken grounds that the CI test workflows would already have taken care of cloning all submodules (ever since 4eef3ec when the "submodules: recursive" option was added to the actions/checkout step). This changes the init-tests-after-clone.sh script to again run that command unconditionally, including on CI. The assumption that it wasn't needed on CI was based on the specific content of GitPython's own GitHub Actions workflows. But this disregarded that the test suite is run on CI for *other* projects: specifically, for downstream projects that package GitPython. --- init-tests-after-clone.sh | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/init-tests-after-clone.sh b/init-tests-after-clone.sh index 21d1f86d8..118e1de22 100755 --- a/init-tests-after-clone.sh +++ b/init-tests-after-clone.sh @@ -47,10 +47,8 @@ git reset --hard HEAD~1 # Point the master branch where we started, so we test the correct code. git reset --hard __testing_point__ -# The tests need submodules. (On CI, they would already have been checked out.) -if ! ci; then - git submodule update --init --recursive -fi +# The tests need submodules, including a submodule with a submodule. +git submodule update --init --recursive # The tests need some version tags. Try to get them even in forks. This fetches # other objects too. So, locally, we always do it, for a consistent experience.