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

Jenkins build using TOPIC

    XMLWordPrintable

Details

    Description

      Hi,

      Is Jenkins can build the job using more than one repo (like repo1, repo2, ..  all changed need to be included in one build) and with same branch using TOPIC.

      Here is the more explanation:

      We use "repo sync" to pull the latest changes from dev branch (it is based on manifest file how we configure) from our host repository. My requirement is something like below:

      $ cd <WORKING_DIR1>

      $ repo sync

      $ cd <repo1>

      made some change, add and then push to gerrit using topic called "new-updates"

      $ cd ../<repo2>

      In repo2 also made some change, add and then push to gerrit using the same topic called "new-updates" . (So I pushed changes of repo1 and repo2 into gerrit using the same topic called "new-updates")

      My requirement:

      Here my requirement is Jenkins needs to trigger the build from gerrit using repo1 and repo2 changes (by using TOPIC called "new-updates"). I know Jenkins can trigger the build using one repo but I want Jenkins should use two changes (from repo1 and repo2) in one build using topic.

      Can you let me know if there is any such solution.

      Thanks

      Laxma

      Attachments

        Activity

          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 Luca Domenico Milanesio added a comment - 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?
          inegm Islam Negm added a comment - - edited

          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. 

          inegm Islam Negm added a comment - - edited 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?

          lucamilanesio Luca Domenico Milanesio added a comment - 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?
          haseneder Rainer Haseneder added a comment - - edited

          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

           

          haseneder Rainer Haseneder added a comment - - edited 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  
          romanz Roman Zwi added a comment -

          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

          romanz Roman Zwi added a comment - 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

          People

            lucamilanesio Luca Domenico Milanesio
            lrdy_scm Laxma Reddy
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated: