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

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

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

              Created:
              Updated: