Build not triggered after fetching submodule failed

Hi,

today i had a configuration that did not build. There is a trigger, that did not fire. The problem was a submodule for which the changes were not pushed to the server. Thus the superproject could not get the changeset. After pushing the submodule changeset, refreshing the Repo did not help. A reset was necessary to get the configuration running again. This should not have been necessary, imo.

Also there was no visible indication in the UI that the Configuration stopped working. No obvious indication why the trigger did not build the configuration. Only checking the tab “REPOSITORIES” of the configuration gave an indication of the problem. Also the admin got a notification of the problem. The UI should allow to spot hanging configurations more easily.

Hi Thomas,

I’m not sure if I’ve understood this correctly, but you appear to be expecting the trigger to fire when there is a new commit on a Git submodule.

Each Git repository in Continua CI only detects changes on one actual Git repository. It does not iterate through each submodule and detect changes for each. For a trigger to fire, there must be a commit to the main repository. If the recursive option is set, then the submodules are updated only when a commit on the main repository is checked out to the working folder. If you added a new commit to the main repository after adding the commit to the submodule, then the submodule change would be picked up as part of the commit to the main repository.

We have been looking into ways to automatically detect changes to git submodules - there are some new git commands available now which were not available when the git repositories were first implemented. There are quite a lot of changes to do to get this right but hope to get this added at some stage in the future.

Meanwhile, if you want to trigger when a commit is made to a submodule, you will need to add a new Continua CI Git repository pointing to the submodule repository and use repository rules to place the files in the correct location at the start of the build stage.

If no change is detected, then Continua CI doesn’t know that there was a problem to report.

What indication did you see on this page and what notification did you get?

I’m not sure what you mean by the configuration hanging - my understanding I that the trigger is not detecting a change to a submodule?

Hi Dave,

this is a misunderstanding. I don’t expect changes in a submodule to trigger a build.

The situation that failed:

  • submodule committed changes, but did NOT push them to the server
  • superproject committed changes including a ref update to the local submodule changes
  • superproject pushed to the server
  • webhook notification send to Continua
  • Continua trying to get the superproject changes

ERROR: These can not be checked out, because of the missing changes in the submodule. This is my fault, because i forgot to push the submodule changes.

The reason for my post is the way Continua handled that situation. After the superproject could not be checked out a little red circle with a white cross is shown on the tab “repositories”.

Now i pushed my submodule changes. I clicked refresh on the repositories tab, but it got stuck on another branch. It did not switch back to master. Only resetting the repo as an admin solved the issue.

Hi Thomas,

Can you post the full error message from the event log? We look into what we can to handle this better tomorrow.

Here we go:

A new event has been added to the event log:
Repository Cannot get changes for repository @link(2002, GUID)[Repo]: Running ‘git.exe’ with arguments “fetch --prune --all” failed with return code 1 and error output: "Fetching origin From [URL] 273981a56…aec178a master → origin/master Fetching submodule Libs/MyLib fatal: git fetch-pack: expected ACK/NAK, got ‘?TF401035: Das Objekt ‘HASH’ ist nicht vorhanden.’ fatal: the remote end hung up unexpectedly Errors during submodule fetch: Libs/MyLib error: Could not fetch origin "

Hint: HASH and URL are replacements for the original values.

v1.9.2.688 includes an update to dry run the git fetch command first. This means that errors of this type do not affect the fetch status so, once the error is corrected, a subsequent call the git fetch will not miss the changeset.

1 Like