Thank you for raising this: the current plugin is tightly coupled at the moment with the Jenkinsfile pipelines, which are tried to a single repository.

I believe your use-case would still make sense if a top-level repository (i.e. the super-project) would be used as common collector of all changes across repositories. Then the top-level repository could have a Jenkinsfile associated and that could get the subprojects tied to a topic.

What do you think?

lucamilanesio

Hello Luca, 

I wonder if this is supported now, do you have any updates about this topic?

Thanks in advance.

Edit#1: I've also changed the ticket priority to be blocker, as in my team we're working with this paradigm mentioned in the ticket description and we want to add the Jenkins verification functionality to the sub-module code review. And this is crucial for us to move on. 

I believe this is more a problem on the multi-branch pipeline concept in Jenkins: where would the Jenkinsfile be stored? one repo? both? Where would you fetch the pipelines from?

I think this is just a bit too difficult to handle on Jenkins level for Jenkins, because Jenkins doesn't know about topics in Gerrit reviews.

We have the same need in our development process now and have convened to implementing following solution in the preparation Python script in our pipeline:

• retrieve all Gerrit reviews that a regrouped in the same topic:
  ssh -p 29418 gerrit.ext.net.nokia.com gerrit query --patch-sets "topic:{TestTopic1}"
  change I<id>
  project: <repo-name>
  branch: <branch>
  topic: <topic>
  id: I<id>
  number: <Gerrit Review number>
  ...
• check for the last n proceeding build numbers if there is a Gerrit review that belongs to the topic (to be investigated how to do it)
  • If true, then do no continue execution of the pipeline and put a comment in the build description

We have similar needs and created some scripts to solve it like this:

• we have superrepos with several submodules
  this description applies for the case that the build has been triggered by a change in one of the submodules (and topic is "new-updates")
• first we clone the superrepo
  then we check if there is an open change with topic "new-updates" in the superrepo
• if yes: fetch and check it out (including subrepos)
• if no: go through all submodules and get open changes with topic "new-updates" (if existing)
• checkout the change that triggered the build (just in case it hasn't been checked out by the previous step)
• we just have to take care that all changes are submitted together because these scripts only find open changes (as we don't want to get outdated stuff with accidently the same topic)

we use ssh queries to get informations about Gerrit topic/changes