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

Mercurial branch option doesn't expand parameters

    Details

    • Type: Improvement
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: mercurial-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      I have a parametrized job, with a TAG parameter (a string). I've used ${TAG} as
      the "branch" option for the Mercurial repository, but in the console log I see
      stuff such as

      hg .... -r ${TAG}

      that makes me thing that the parameter is not expanded.

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment -

            It is covered by a separate issue, JENKINS-5396. Supporting that would likely require major changes to the plugin, since polling and changelogs are senseless in this case. Probably you should not even use the plugin at all (just add a build step to update your working copy) to the specified revision; currently the only value the plugin can add for this use case is to enable usage of cache repositories.

            Show
            jglick Jesse Glick added a comment - It is covered by a separate issue, JENKINS-5396 . Supporting that would likely require major changes to the plugin, since polling and changelogs are senseless in this case. Probably you should not even use the plugin at all (just add a build step to update your working copy) to the specified revision; currently the only value the plugin can add for this use case is to enable usage of cache repositories.
            Hide
            cowwoc cowwoc added a comment -

            Jesse,

            So if I understand you correctly: the mercurial plugin only supports building a specific branch but not a specific revision. Should I file a feature request for the latter or is this covered by a separate issue?

            Show
            cowwoc cowwoc added a comment - Jesse, So if I understand you correctly: the mercurial plugin only supports building a specific branch but not a specific revision. Should I file a feature request for the latter or is this covered by a separate issue?
            Hide
            jglick Jesse Glick added a comment -

            > from now on "Mercurial Polling Log" will use this revision for polling (expected behavior: use the parameter's default value)

            Sorry, but polling can only work when compared to the previous build. You can't switch revisions around and expect the poll or changelog to be meaningful. Read the older comments.

            > Hudson doesn't actually build the revision we asked for

            In your output it is building 41dbb0648c58, which I presume you specified as the revision.

            I think your real problem is that you are trying to build a specific revision rather than a branch, which is not supported. (Filed elsewhere.)

            Show
            jglick Jesse Glick added a comment - > from now on "Mercurial Polling Log" will use this revision for polling (expected behavior: use the parameter's default value) Sorry, but polling can only work when compared to the previous build. You can't switch revisions around and expect the poll or changelog to be meaningful. Read the older comments. > Hudson doesn't actually build the revision we asked for In your output it is building 41dbb0648c58, which I presume you specified as the revision. I think your real problem is that you are trying to build a specific revision rather than a branch, which is not supported. (Filed elsewhere.)
            Hide
            cowwoc cowwoc added a comment -

            Jesse,

            I think there is a bug with this fix. Here is what I did:

            1. Create a build parameter "revision" with a default value containing your default branch
            2. Set the "branch" field to "${revision}"
            3. Invoke "Build Now" with revision = foo
            4. Notice that from now on "Mercurial Polling Log" will use this revision for polling (expected behavior: use the parameter's default value)
            5. Secondly, we've noticed that Hudson doesn't actually build the revision we asked for. Here is the console output for your review:

            Started by user anonymous
            Building on master
            [workspace] $ hg update --clean .
            0 files updated, 0 files merged, 0 files removed, 0 files unresolved
            [workspace] $ hg --config extensions.purge= clean --all
            [workspace] $ hg incoming --quiet --bundle hg.bundle --template "<changeset node='{node}' author='{author|xmlescape}' rev='{rev}' date='{date}'><msg>{desc|xmlescape}</msg><added>{file_adds|stringify|xmlescape}</added><deleted>{file_dels|stringify|xmlescape}</deleted><files>{files|stringify|xmlescape}</files><parents>{parents}</parents></changeset>\n" --rev "41dbb0648c58 "
            [workspace] $ hg log --rev . --template {node}
            [workspace] $ /bin/sh -xe /tmp/hudson7442837258106398855.sh
            Started indexing related Jira issue keys
            Successfully indexed related Jira issue keys
            Finished: SUCCESS

            I believe it built "tip" instead.

            Show
            cowwoc cowwoc added a comment - Jesse, I think there is a bug with this fix. Here is what I did: Create a build parameter "revision" with a default value containing your default branch Set the "branch" field to "${revision}" Invoke "Build Now" with revision = foo Notice that from now on "Mercurial Polling Log" will use this revision for polling (expected behavior: use the parameter's default value) Secondly, we've noticed that Hudson doesn't actually build the revision we asked for. Here is the console output for your review: Started by user anonymous Building on master [workspace] $ hg update --clean . 0 files updated, 0 files merged, 0 files removed, 0 files unresolved [workspace] $ hg --config extensions.purge= clean --all [workspace] $ hg incoming --quiet --bundle hg.bundle --template "<changeset node='{node}' author='{author|xmlescape}' rev='{rev}' date='{date}'><msg>{desc|xmlescape}</msg><added>{file_adds|stringify|xmlescape}</added><deleted>{file_dels|stringify|xmlescape}</deleted><files>{files|stringify|xmlescape}</files><parents>{parents}</parents></changeset>\n" --rev "41dbb0648c58 " [workspace] $ hg log --rev . --template {node} [workspace] $ /bin/sh -xe /tmp/hudson7442837258106398855.sh Started indexing related Jira issue keys Successfully indexed related Jira issue keys Finished: SUCCESS I believe it built "tip" instead.
            Hide
            jglick Jesse Glick added a comment -

            Not sure what you mean by "subjobs". http://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build (and my experiments) just involve a single job to which you can apply your choice of parameters for a given build. If you are talking about some other scenario I don't know about, that would probably be a separate issue report (and please include detailed steps to reproduce from scratch). Perhaps you meant to be looking at JENKINS-3907.

            Show
            jglick Jesse Glick added a comment - Not sure what you mean by "subjobs". http://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build (and my experiments) just involve a single job to which you can apply your choice of parameters for a given build. If you are talking about some other scenario I don't know about, that would probably be a separate issue report (and please include detailed steps to reproduce from scratch). Perhaps you meant to be looking at JENKINS-3907 .

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                fabriziogiudici fabriziogiudici
              • Votes:
                2 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: