I believe this bug is more serious and could use more attention. Right now submodules behave differently from top-level repositories and builds can run with a broken or stale submodule checkout. It doesn't even take a misbehaving build step – if a build is aborted while checking out submodules, it will leave the submodule dirty. Subsequent builds in this workspace will then to not update the submodule at all, while not producing any useful diagnostics.
This can be reproduced with a simple job restricted to one node, and a helper git repository with a submodule:
# create submodule repository
(mkdir sub && cd sub && git init && echo sub>file && git commit -a -msub)
# create outer repository
(mkdir outer && cd outer && git init && echo outer>file && submodule add ../sub && git commit -a -mouter)
Configure a job to use the outer repository with git advanced behavior "Recursively update submodules" checked and the following execute shell build step:
cat file
cat sub/file
# simulate modified workspace / aborted checkout
rm file
rm sub/file
When the job is run the first time, the output is as expected; "outer" and "sub". The second time "outer" is printed because the plugin issued a "checkout -f", but the build fails because sub/file is still gone. There is no error message during the git step. This means currently it's very risky to use submodules with the git plugin unless workspaces or checkouts are force-cleaned: at best you'll sometimes get a build error, at worst – silent build corruption by using stale sources.
I believe this bug is more serious and could use more attention. Right now submodules behave differently from top-level repositories and builds can run with a broken or stale submodule checkout. It doesn't even take a misbehaving build step – if a build is aborted while checking out submodules, it will leave the submodule dirty. Subsequent builds in this workspace will then to not update the submodule at all, while not producing any useful diagnostics.
This can be reproduced with a simple job restricted to one node, and a helper git repository with a submodule:
Configure a job to use the outer repository with git advanced behavior "Recursively update submodules" checked and the following execute shell build step:
When the job is run the first time, the output is as expected; "outer" and "sub". The second time "outer" is printed because the plugin issued a "checkout -f", but the build fails because sub/file is still gone. There is no error message during the git step. This means currently it's very risky to use submodules with the git plugin unless workspaces or checkouts are force-cleaned: at best you'll sometimes get a build error, at worst – silent build corruption by using stale sources.