The issue is with timing. When Continua CI detects a new git commit, it then checks out the commit to the cache folder, updates any submodules, creates the changeset details file using “git submodule status” to get the submodule details, and then commits everything to the repository cache. At this point, a build can be triggered using the files in the repository cache, before any tag is added to the commit in the submodule. The Continua CI changeset is basically a representation of the state of the repository commit at the time it is stored in the repository cache.
We could wait for a while, before committing to the repository cache, to see if any tags are added to the commit - but how long should we wait? We don’t want to hold up the build. Alternatively, we could update an existing repository cache entry (and changeset) when we detect a tag change, but it may be too late - the build may have already been triggered.
If “Tag Changes” is set to “Detect And List As New Changeset”, Continua CI currently creates a new entry in the repository cache and a new virtual changeset in the database when a tag change is detected on the main repository. A build can then be triggered on the “tag change” changeset. We could do a similar thing with new tags detected on submodules. We’ll look into this option, but don’t expect anything until after the holidays.