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

Mercurial - paths.default is set incorrectly at checkout

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • mercurial-plugin
    • None
    • jenkins 2.284
      Mercurial plugin 2.14
    • 2.16

      With latest version of Mercurial plugin (2.14), the Mercurial clone configuration is not correct.

      The "paths.default" does not contains the Repo URL, but instead it contains the clone PATH on the file system followed by the Repo URL.

      For instance:
      paths.default=/var/lib/jenkins/workspace/my_job/https\:/hg.mydns.com/hg/myrepo

       

      instead of:

      paths.default=https://hg.mydns.com/hg/myrepo

       

      the problem appeared since version 2.14. After rollback to plugin 2.12, no issues.

       

      because of this, we cannot run "hg push" command as the URL is incorrect in the local repo

          [JENKINS-65175] Mercurial - paths.default is set incorrectly at checkout

          Alexander Mai added a comment - - edited

          I can confirm that issue and the workaround via downgrade.

          IIRC I've seen it on Windows.

          Alexander Mai added a comment - - edited I can confirm that issue and the workaround via downgrade. IIRC I've seen it on Windows.

          Kanstantsin Shautsou added a comment - - edited

          Downgrade didn't help.
          Got the same issue for fresh created multibranch job on updated plugin version (fresh created caches).
          Job that was created and had caches from old plugins (not only mercurial?) version still work fine.
          Not sure how all this may be related, but the only things that i found now.

          Running in Durability level: MAX_SURVIVABILITY
          [Pipeline] Start of Pipeline
          [Pipeline] node
          Running on slave-agent in /home/jenkins-agent/workspace/project-name_branch
          [Pipeline] {
          [Pipeline] stage
          [Pipeline] { (checkout)
          Acquired master cache lock.
          [80DF6D85F87A3746F68AEEB8EE1DCF5DF504B7EB-project-name-some.creds] $ hg --config auth.jenkins.prefix=* --config ******** --config ******** --config "auth.jenkins.schemes=http https" pull
          pulling from https://repository.comm/scm/hg/project-name
          searching for changes
          no changes found
          Master cache lock released.
          [80DF6D85F87A3746F68AEEB8EE1DCF5DF504B7EB-project-name-some.creds] $ hg --config auth.jenkins.prefix=* --config ******** --config ******** --config "auth.jenkins.schemes=http https" heads --template "{node} {branch}\n"
          Found branch demo
            Met criteria
          Processed 1 branches (query complete)
          [Pipeline] checkout
          [project-name_branch] $ hg --config auth.jenkins.prefix=* --config ******** --config ******** --config "auth.jenkins.schemes=http https" showconfig paths.default
          ERROR: Workspace reports paths.default as /home/jenkins-agent/workspace/project-name_branch/https\:/repository.comm/scm/hg/project-name
          which looks different than https://repository.comm/scm/hg/project-name
          so falling back to fresh clone rather than incremental update
          Acquired master cache lock.
          [80DF6D85F87A3746F68AEEB8EE1DCF5DF504B7EB-project-name-some.creds] $ hg --config auth.jenkins.prefix=* --config ******** --config ******** --config "auth.jenkins.schemes=http https" pull
          pulling from https://repository.comm/scm/hg/project-name
          searching for changes
          no changes found
          Master cache lock released.
          Acquired slave node cache lock for node slave-agent.
          
          

          After build ends .hg/hgrc contains correct default path in .hg/hgrc

          mercurial: 2.14 or 2.12
          branch-api: 2.6.2
          multibranch-scan-webhook-trigger:1.0.5
          workflow-multibranch:2.23
          scm-api:2.6.4
          credentials:2.3.18
          workflow-scm-step:2.12
          inline-pipeline:1.0.1

           

          In the same time there is some issue with full scan (the only way now to trigger plain mercurial multibranch) that ends with 5-6 spawned builds for the same commit, every has the same Branch indexing reason. Note: repository is pretty huge ~15GB

          Kanstantsin Shautsou added a comment - - edited Downgrade didn't help. Got the same issue for fresh created multibranch job on updated plugin version (fresh created caches). Job that was created and had caches from old plugins (not only mercurial?) version still work fine. Not sure how all this may be related, but the only things that i found now. Running in Durability level: MAX_SURVIVABILITY [Pipeline] Start of Pipeline [Pipeline] node Running on slave-agent in /home/jenkins-agent/workspace/project-name_branch [Pipeline] { [Pipeline] stage [Pipeline] { (checkout) Acquired master cache lock. [80DF6D85F87A3746F68AEEB8EE1DCF5DF504B7EB-project-name-some.creds] $ hg --config auth.jenkins.prefix=* --config ******** --config ******** --config "auth.jenkins.schemes=http https" pull pulling from https: //repository.comm/scm/hg/project-name searching for changes no changes found Master cache lock released. [80DF6D85F87A3746F68AEEB8EE1DCF5DF504B7EB-project-name-some.creds] $ hg --config auth.jenkins.prefix=* --config ******** --config ******** --config "auth.jenkins.schemes=http https" heads --template "{node} {branch}\n" Found branch demo Met criteria Processed 1 branches (query complete) [Pipeline] checkout [project-name_branch] $ hg --config auth.jenkins.prefix=* --config ******** --config ******** --config "auth.jenkins.schemes=http https" showconfig paths. default ERROR: Workspace reports paths. default as /home/jenkins-agent/workspace/project-name_branch/https\:/repository.comm/scm/hg/project-name which looks different than https: //repository.comm/scm/hg/project-name so falling back to fresh clone rather than incremental update Acquired master cache lock. [80DF6D85F87A3746F68AEEB8EE1DCF5DF504B7EB-project-name-some.creds] $ hg --config auth.jenkins.prefix=* --config ******** --config ******** --config "auth.jenkins.schemes=http https" pull pulling from https: //repository.comm/scm/hg/project-name searching for changes no changes found Master cache lock released. Acquired slave node cache lock for node slave-agent. After build ends .hg/hgrc contains correct default path in .hg/hgrc mercurial: 2.14 or 2.12 branch-api: 2.6.2 multibranch-scan-webhook-trigger:1.0.5 workflow-multibranch:2.23 scm-api:2.6.4 credentials:2.3.18 workflow-scm-step:2.12 inline-pipeline:1.0.1   In the same time there is some issue with full scan (the only way now to trigger plain mercurial multibranch) that ends with 5-6 spawned builds for the same commit, every has the same Branch indexing reason. Note: repository is pretty huge ~15GB

          Jesse Glick added a comment -

          Not sure offhand what might be going on. Changes in recent versions of Mercurial itself? I think I was testing with 5.5.1 just because that is what Ubuntu currently offers as a package, though 5.8 is the current download.

          Note that most functional tests, including all tests involving a “caching” installation and thus multibranch Pipelines, test against hg found in $PATH of the test machine; the ability to run Dockerized tests which check behavior of specific Mercurial (and Python) versions are restricted for now to scenarios which only run Mercurial from agent launchers and never from the controller. (In the future I would expect RealJenkinsRule to be able to address this. It would need to be extended to permit the controller JVM to be run from Docker rather than locally.)

          Beware that I have not used Mercurial (except for testing this plugin) in close to nine years, and it is up for adoption. It would be great to pass it off to a maintainer who actually runs Mercurial in production and better understands recent developments, as well as having Jenkins plugin expertise. Currently my employer expects the plugin to be maintained at a basic level (e.g., passing plugin-compat-tester against new core LTS lines) but this is really for historical reasons, and because it was a dependency of the Bitbucket Branch Source plugin (which is no longer the case).

          Jesse Glick added a comment - Not sure offhand what might be going on. Changes in recent versions of Mercurial itself? I think I was testing with 5.5.1 just because that is what Ubuntu currently offers as a package, though 5.8 is the current download. Note that most functional tests, including all tests involving a “caching” installation and thus multibranch Pipelines, test against hg found in $PATH of the test machine; the ability to run Dockerized tests which check behavior of specific Mercurial (and Python) versions are restricted for now to scenarios which only run Mercurial from agent launchers and never from the controller. (In the future I would expect RealJenkinsRule to be able to address this. It would need to be extended to permit the controller JVM to be run from Docker rather than locally.) Beware that I have not used Mercurial (except for testing this plugin) in close to nine years, and it is up for adoption. It would be great to pass it off to a maintainer who actually runs Mercurial in production and better understands recent developments, as well as having Jenkins plugin expertise. Currently my employer expects the plugin to be maintained at a basic level (e.g., passing plugin-compat-tester against new core LTS lines) but this is really for historical reasons, and because it was a dependency of the Bitbucket Branch Source plugin (which is no longer the case).

          Kanstantsin Shautsou added a comment - - edited

          In my case hg is 5.5.2 on master and slaves.
          According to code comment getSource() may contain either path either url and it seems it extracted/set from env object. The only place related to set "paths" "default" i see in caches

          Kanstantsin Shautsou added a comment - - edited In my case hg is 5.5.2 on master and slaves. According to code comment getSource() may contain either path either url and it seems it extracted/set from env object. The only place related to set "paths" "default" i see in caches

          Alexander Mai added a comment -

          On my Windows slaves I use Mercurial Distributed SCM (version 5.0.2)

          Mercurial on Linux master is even older: Mercurial Distributed SCM (version 4.5.2)

          Alexander Mai added a comment - On my Windows slaves I use Mercurial Distributed SCM (version 5.0.2) Mercurial on Linux master is even older: Mercurial Distributed SCM (version 4.5.2)

          Oleg Kalugin added a comment -

          The path that gets saved in .hg/hgrc gets the colon escaped. So instead of being like "ssh://my-repo" it becomes "ssh\://my-repo"
          So mercurial then barfs when attempting to use that path. When I fixed the path in hgrc, it let me push successfully

          Oleg Kalugin added a comment - The path that gets saved in .hg/hgrc gets the colon escaped. So instead of being like "ssh://my-repo" it becomes "ssh\://my-repo" So mercurial then barfs when attempting to use that path. When I fixed the path in hgrc, it let me push successfully

          Andrew Zwicky added a comment - - edited

          I can confirm the same issue was present at 2.15, and a downgrade to 2.12 solved the issue as well.

          We are running Mercurial Distributed SCM (version 4.2.1)

          Andrew Zwicky added a comment - - edited I can confirm the same issue was present at 2.15, and a downgrade to 2.12 solved the issue as well. We are running Mercurial Distributed SCM (version 4.2.1)

          Jesse Glick added a comment -

          I have filed a proposed fix. If there is anyone able to reproduce, please try to verify the fix. Assuming the pull request build succeeds, there should be a continuous-integration/jenkins/incrementals link available soon https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/mercurial/2.16-rc1210.a462f72c1bdd/mercurial-2.16-rc1210.a462f72c1bdd.hpi which you can download and install in a Jenkins server using the Advanced tab of the plugin manager.

          Jesse Glick added a comment - I have filed a proposed fix. If there is anyone able to reproduce, please try to verify the fix. Assuming the pull request build succeeds, there should be a continuous-integration/jenkins/incrementals link available soon https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/mercurial/2.16-rc1210.a462f72c1bdd/mercurial-2.16-rc1210.a462f72c1bdd.hpi which you can download and install in a Jenkins server using the Advanced tab of the plugin manager.

          It is working on my platform with this latest update. I was able to build and commit using this latest plugin.

          Thanks.

          Nicolas Letolle added a comment - It is working on my platform with this latest update. I was able to build and commit using this latest plugin. Thanks.

          Jesse Glick added a comment -

          nletolle thanks for confirming! I will proceed with a merge and release then.

          Jesse Glick added a comment - nletolle thanks for confirming! I will proceed with a merge and release then.

            jglick Jesse Glick
            nletolle Nicolas Letolle
            Votes:
            3 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: