I have a Jenkins job that performs polling of an SVN trunk and launches a complex chain of jobs if the trunk was updated.

      What I'd like to do is to give users the ability to launch the job manually, specifying a different branch to checkout - e.g., to test the code in a branch before merging it to the trunk. Currently, I can do the following:

      • Set the Repository URL to https://svn/$BRANCH
      • Set the default value of parameter BRANCH to trunk/xyz
      • Let users type in the branch, OR use the List Subversion Tags option

      However, this does not work as expected – or maybe I have misinterpreted the behavior, in which case please correct me.
      The way I understand it, such configuration works like this:
      0) I set up the job as described above
      1) The job is polling the trunk, since this is the default value of the parameter
      2) I launch the job manually, choosing a different branch to checkout. It runs successfully
      3) After that, the job begins to poll the branch instead of the trunk. This is absolutely not what I expect it to do – manual launches should not interfere with future automatic polling.

      I understand this is the way Jenkins works with parameters, so I am filing this as a feature request.

          [JENKINS-17867] Allow manual builds of different branches

          Alex Vesely created issue -
          Alex Vesely made changes -
          Description Original: I have a Jenkins job that performs polling of an SVN trunk and launches a complex chain of jobs if the trunk was updated.

          What I'd like to do is to give users the ability to launch the job manually, specifying a different branch to checkout - e.g., to test the code in a branch before merging it to the trunk. Currently, I can do the following:

          - Set the Repository URL to https://svn/$BRANCH
          - Set the default value of parameter BRANCH to trunk/xyz, OR use the List Subversion Tags option

          However, this does not work as expected -- or maybe I have misinterpreted the behavior, in which case please correct me.
          The way I understand it, such configuration works like this:
          0) I set up the job as described above
          1) The job is polling the trunk, since this is the default value of the parameter
          2) I launch the job manually, choosing a different branch to checkout. It runs successfully
          3) After that, the job begins to poll the branch instead of the trunk. This is absolutely not what I expect it to do -- manual launches should not interfere with future automatic polling.

          I understand this is the way Jenkins works with parameters, so I am filing this as a feature request.
          New: I have a Jenkins job that performs polling of an SVN trunk and launches a complex chain of jobs if the trunk was updated.

          What I'd like to do is to give users the ability to launch the job manually, specifying a different branch to checkout - e.g., to test the code in a branch before merging it to the trunk. Currently, I can do the following:

          - Set the Repository URL to https://svn/$BRANCH
          - Set the default value of parameter BRANCH to trunk/xyz
          - Let users type in the branch, OR use the List Subversion Tags option

          However, this does not work as expected -- or maybe I have misinterpreted the behavior, in which case please correct me.
          The way I understand it, such configuration works like this:
          0) I set up the job as described above
          1) The job is polling the trunk, since this is the default value of the parameter
          2) I launch the job manually, choosing a different branch to checkout. It runs successfully
          3) After that, the job begins to poll the branch instead of the trunk. This is absolutely not what I expect it to do -- manual launches should not interfere with future automatic polling.

          I understand this is the way Jenkins works with parameters, so I am filing this as a feature request.

          binary added a comment - - edited

          This was unexpected to us as well. Additionally, few days ago the job somehow switched back to "trunk" few minutes after it was run manually to test a branch. Later, both "chains" of builds mixed together, i.e., triggered a single downstream build from two different upstream builds. Upstream builds had different parameters which are passed to downstream jobs, therefore there had to be 2 downstream builds to test both branch and trunk.

          Possible workaround for polling issue - remove SCM polling from your "starter job" and add 2 new jobs - one for polling (set depths to "empty"), another for running it manually. Then, use "Trigger parameterized build on other projects" to run your current "starter job".

          binary added a comment - - edited This was unexpected to us as well. Additionally, few days ago the job somehow switched back to "trunk" few minutes after it was run manually to test a branch. Later, both "chains" of builds mixed together, i.e., triggered a single downstream build from two different upstream builds. Upstream builds had different parameters which are passed to downstream jobs, therefore there had to be 2 downstream builds to test both branch and trunk. Possible workaround for polling issue - remove SCM polling from your "starter job" and add 2 new jobs - one for polling (set depths to "empty"), another for running it manually. Then, use "Trigger parameterized build on other projects" to run your current "starter job".
          Yoichi Nakayama made changes -
          Link New: This issue is related to JENKINS-20463 [ JENKINS-20463 ]
          Yoichi Nakayama made changes -
          Link New: This issue duplicates JENKINS-14326 [ JENKINS-14326 ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 149163 ] New: JNJira + In-Review [ 177270 ]

            Unassigned Unassigned
            alex01ves Alex Vesely
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: