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

            fabriziogiudici fabriziogiudici created issue -
            Hide
            jglick Jesse Glick added a comment -

            I don't think this was ever intended to be supported. It could be.

            Show
            jglick Jesse Glick added a comment - I don't think this was ever intended to be supported. It could be.
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Assignee kohsuke [ kohsuke ] jglick [ jglick ]
            Hide
            mfriedenhagen Mirko Friedenhagen added a comment -

            Hm, subversion seems to support this. I had a job once, where I could switch between trunk and branches/stable via a parameter SVN_BRANCH and Hudson was expanding my parameter.

            Show
            mfriedenhagen Mirko Friedenhagen added a comment - Hm, subversion seems to support this. I had a job once, where I could switch between trunk and branches/stable via a parameter SVN_BRANCH and Hudson was expanding my parameter.
            Hide
            cdevienne cdevienne added a comment -

            Same issue for me. I need this feature to use hudson to produce my build releases.

            I am willing to do tests if needed.

            Thanks,

            Christophe

            Show
            cdevienne cdevienne added a comment - Same issue for me. I need this feature to use hudson to produce my build releases. I am willing to do tests if needed. Thanks, Christophe
            jglick Jesse Glick made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            Hide
            jglick Jesse Glick added a comment -

            It actually mostly worked already except that:

            1. Polling did not work.

            2. "-r ${TAG}" is printed to console even though it is actually expanding the parameter when running hg.

            Show
            jglick Jesse Glick added a comment - It actually mostly worked already except that: 1. Polling did not work. 2. "-r ${TAG}" is printed to console even though it is actually expanding the parameter when running hg.
            Hide
            jglick Jesse Glick added a comment -

            Note that polling is not likely to be useful anyway; as warned at

            http://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build

            "When build triggers are used to start a build, there's no way to pass parameters. This includes SCM polling, downstream builds, and periodic builds. Instead, the specified default values will be used for string, boolean and choice parameters."

            I will implement SCM triggers based on the branch used for the last build, but when the build is actually triggered, Hudson will switch it to the default branch anyway. Not much to be done about that in the Mercurial plugin. Arguably Hudson core should pass the same parameters as the last build used when a build is triggered by an automatic cause.

            Show
            jglick Jesse Glick added a comment - Note that polling is not likely to be useful anyway; as warned at http://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build "When build triggers are used to start a build, there's no way to pass parameters. This includes SCM polling, downstream builds, and periodic builds. Instead, the specified default values will be used for string, boolean and choice parameters." I will implement SCM triggers based on the branch used for the last build, but when the build is actually triggered, Hudson will switch it to the default branch anyway. Not much to be done about that in the Mercurial plugin. Arguably Hudson core should pass the same parameters as the last build used when a build is triggered by an automatic cause.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : jglick
            Path:
            trunk/hudson/plugins/mercurial/pom.xml
            trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialSCM.java
            trunk/hudson/plugins/mercurial/src/test/java/hudson/plugins/mercurial/MercurialSCMTest.java
            trunk/hudson/plugins/mercurial/src/test/java/hudson/plugins/mercurial/MercurialTestCase.java
            http://jenkins-ci.org/commit/26453
            Log:
            [FIXED JENKINS-4271] Support parameters in the "branch" field of Hg job config.
            Really just means (1) printing a better message to console;
            (2) polling from the branch used by the last build (though a triggered build will currently use the default value anyway).
            Not doing anything to support parameters in the repository location, modules list, or other fields.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : jglick Path: trunk/hudson/plugins/mercurial/pom.xml trunk/hudson/plugins/mercurial/src/main/java/hudson/plugins/mercurial/MercurialSCM.java trunk/hudson/plugins/mercurial/src/test/java/hudson/plugins/mercurial/MercurialSCMTest.java trunk/hudson/plugins/mercurial/src/test/java/hudson/plugins/mercurial/MercurialTestCase.java http://jenkins-ci.org/commit/26453 Log: [FIXED JENKINS-4271] Support parameters in the "branch" field of Hg job config. Really just means (1) printing a better message to console; (2) polling from the branch used by the last build (though a triggered build will currently use the default value anyway). Not doing anything to support parameters in the repository location, modules list, or other fields.
            scm_issue_link SCM/JIRA link daemon made changes -
            Status In Progress [ 3 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            mhenoch mhenoch added a comment -

            I might be missing something, but wouldn't it be more useful to poll without specifying any branch for parameterized builds? That way, if there are any new commits at all, builds would be triggered for all the subjobs, of which at least one should have something new on the branch it's following.

            Show
            mhenoch mhenoch added a comment - I might be missing something, but wouldn't it be more useful to poll without specifying any branch for parameterized builds? That way, if there are any new commits at all, builds would be triggered for all the subjobs, of which at least one should have something new on the branch it's following.
            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 .
            paul_cannell paul_cannell made changes -
            Link This issue is related to JENKINS-7361 [ JENKINS-7361 ]
            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.
            cowwoc cowwoc made changes -
            Resolution Fixed [ 1 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            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.)
            jglick Jesse Glick made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            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 -

            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.
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 134344 ] JNJira + In-Review [ 186792 ]

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: