Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-27625

Git submodules, option for reseting local changes on submodules

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • 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

          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.

          Tomasz Śniatowski added a comment - 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.

          This problem is still present in current git plugin master (06415b9b9d3dd46d11a620b78ff56b19847c141a)

          Tomasz Śniatowski added a comment - This problem is still present in current git plugin master (06415b9b9d3dd46d11a620b78ff56b19847c141a)

            Unassigned Unassigned
            fantastory Roman Wieczorek
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: