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

Allow manual builds of different branches

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

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

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

              People

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

                Dates

                • Created:
                  Updated: