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.
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?
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.
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.