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

Mercurial branch option doesn't support specifying named branch and revision

    Details

    • Similar Issues:

      Description

      In the mercurial branch option field you can specify a named branch such as default or you can specify a revision number given by a named parameter (using the parametrized build plugin).

      You can not specify a named branch and provide a revision number simultaneously.

        Attachments

          Issue Links

            Activity

            Hide
            paul_cannell paul_cannell added a comment - - edited

            It would be very useful to be able to build specific revisions of a named branch which was forked off of the repository default branch.

            Show
            paul_cannell paul_cannell added a comment - - edited It would be very useful to be able to build specific revisions of a named branch which was forked off of the repository default branch.
            Hide
            jglick Jesse Glick added a comment -

            If you specify a revision, there is no meaning to the branch parameter.

            Anyway for now there is intentionally no support for specifying a tag or other fixed revision, since then there would be no polling, updating, or changelog calculation.

            Show
            jglick Jesse Glick added a comment - If you specify a revision, there is no meaning to the branch parameter. Anyway for now there is intentionally no support for specifying a tag or other fixed revision, since then there would be no polling, updating, or changelog calculation.
            Hide
            cowwoc cowwoc added a comment -

            Correct me if I'm wrong Paul, but I believe we already solved this problem.

            Our use-case is as follows:

            1. QA reports a bug in a specific build
            2. Hudson doesn't have this build available (maybe it got deleted because it was too old)
            3. We go into the Hudson project, "Build Now", type in the revision number we're interested in and Hudson runs "hg update -b <branch> -r <revision>"

            We implemented this by hard-coding a branch under: Source Code Management -> Mercurial -> Branch.
            We allow users to specify the revision number to build using: "This build is parameterized", name = "revision", default value = "tip"

            So by default Hudson always builds branch/tip but when users select "Build Now" they can specify what specific revision to use.

            Jesse, does this make sense to you?

            Show
            cowwoc cowwoc added a comment - Correct me if I'm wrong Paul, but I believe we already solved this problem. Our use-case is as follows: QA reports a bug in a specific build Hudson doesn't have this build available (maybe it got deleted because it was too old) We go into the Hudson project, "Build Now", type in the revision number we're interested in and Hudson runs "hg update -b <branch> -r <revision>" We implemented this by hard-coding a branch under: Source Code Management -> Mercurial -> Branch. We allow users to specify the revision number to build using: "This build is parameterized", name = "revision", default value = "tip" So by default Hudson always builds branch/tip but when users select "Build Now" they can specify what specific revision to use. Jesse, does this make sense to you?
            Hide
            cowwoc cowwoc added a comment -

            Jesse,

            Upon further investigation, this is a real issue. I just didn't do a good job explaining the problem.

            Our use-case is as follows:

            1. We use the branch-per-release branching strategy, meaning we have one named branch per release. Currently we have two active branches: development-1.2.5 and development-1.3.0
            2. We are expecting separate Branch and Revision configuration fields that will result in the following command-line: "hg update -b <branch> -r <revision>"
            3. We'd hard-code Branch to development-1.2.5 and Revision to "$revision".
            4. "$revision" is defined by "This build is parameterized", name = "revision", default value = "tip"
            5. Builds triggered by polls would work against development-1.2.5/tip whereas builds triggered by users would work against development-1.2.5/$revision

            Please let me know if you see any problem with this.

            Show
            cowwoc cowwoc added a comment - Jesse, Upon further investigation, this is a real issue. I just didn't do a good job explaining the problem. Our use-case is as follows: We use the branch-per-release branching strategy, meaning we have one named branch per release. Currently we have two active branches: development-1.2.5 and development-1.3.0 We are expecting separate Branch and Revision configuration fields that will result in the following command-line: "hg update -b <branch> -r <revision>" We'd hard-code Branch to development-1.2.5 and Revision to "$revision". "$revision" is defined by "This build is parameterized", name = "revision", default value = "tip" Builds triggered by polls would work against development-1.2.5/tip whereas builds triggered by users would work against development-1.2.5/$revision Please let me know if you see any problem with this.
            Hide
            jglick Jesse Glick added a comment -

            'hg up -b development-1.2.5 -r tip' doesn't make sense. 'tip' is the most recently committed or pulled changeset, regardless of branch, so these options conflict.

            I think what you want is two jobs. One would be set to use branch = development-1.2.5 and poll normally, complete with changelog. It should not be used for user-initiated builds since (at least until JENKINS-3235 is implemented) that would mess up the changelog.

            The other would not be parametrized, not use the Hg plugin at all, and simply 'hg clone -r $revision' as part of your build script. It makes no sense for this to have a changelog or polling, so there is little left for the plugin to do.

            Show
            jglick Jesse Glick added a comment - 'hg up -b development-1.2.5 -r tip' doesn't make sense. 'tip' is the most recently committed or pulled changeset, regardless of branch, so these options conflict. I think what you want is two jobs. One would be set to use branch = development-1.2.5 and poll normally, complete with changelog. It should not be used for user-initiated builds since (at least until JENKINS-3235 is implemented) that would mess up the changelog. The other would not be parametrized, not use the Hg plugin at all, and simply 'hg clone -r $revision' as part of your build script. It makes no sense for this to have a changelog or polling, so there is little left for the plugin to do.

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                paul_cannell paul_cannell
              • Votes:
                1 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: