-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
windows 2012R2
Jenkins ver. 1.605
GIT client plugin 1.16.1
GIT plugin 2.3.5
When working with submodules and submodule modifies some tracked files during build,
the consecutive builds will file on submodule update, with a git error of unstaged changes.
Although build should not change tracked files it could happen due to programmer mistake.
One can bypass it with
git submodule foreach git checkout %sha1%
as a first build step
Note that git clean is not an option for builds that uses bower or npm, since they download packages from web, and generally work very long.
[JENKINS-27625] Git submodules, option for reseting local changes on submodules
Description |
Original:
When working with submodules and submodule modifies some tracked files during build, the consecutive builds will file on submodule update, with a git error of unstaged changes. Although build should not change tracked files it could happen due to programmer mistake. One can bypass it with git -C jobs/%JOB_NAME%/workspace/submodule reset --hard || true Note that git clean is not an option for builds that uses bower or npm, since they download packages from web, and generally work very long. |
New:
When working with submodules and submodule modifies some tracked files during build, the consecutive builds will file on submodule update, with a git error of unstaged changes. Although build should not change tracked files it could happen due to programmer mistake. One can bypass it with {{git submodule foreach git checkout %sha1%}} as a first build step Note that git clean is not an option for builds that uses bower or npm, since they download packages from web, and generally work very long. |
Workflow | Original: JNJira [ 161837 ] | New: JNJira + In-Review [ 180861 ] |
Assignee | Original: Nicolas De Loof [ ndeloof ] |
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.