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

Mercurial plugin cloning not resolving environment variables correctly

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • mercurial-plugin
    • None
    • x86_64 SuSE SLES 11

      I am using an environment variable for my Kiln URL and specifying it in the mercurial section under source control. The environment variable is set and gets resolved in the shell when running the hg clone command. However, when the plugin checks if the URL matches what is already in the workspace, it checks against the configured URL before resolving the environment variable (which does not match what is in the hgrc of the workspace). This causes the job to clone every time it runs.

          [JENKINS-15163] Mercurial plugin cloning not resolving environment variables correctly

          I experience a similar issue with mercurial plugin ignoring slave environment variables. HGRCPATH is set in a slave configuration to point to a hgrc file. When the plugin tries, for example, to pull a repo requiring the largefiles extension, it fails with this message:

          abort: unknown repository format: requires features 'largefiles' (upgrade Mercurial)!

          even if the largefiles extension is enabled in the hgrc file pointed by HGRCPATH.

          This works perfectly with a hg pull in a windows batch command.

          Olivier Trempe added a comment - I experience a similar issue with mercurial plugin ignoring slave environment variables. HGRCPATH is set in a slave configuration to point to a hgrc file. When the plugin tries, for example, to pull a repo requiring the largefiles extension, it fails with this message: abort: unknown repository format: requires features 'largefiles' (upgrade Mercurial)! even if the largefiles extension is enabled in the hgrc file pointed by HGRCPATH. This works perfectly with a hg pull in a windows batch command.

          Jesse Glick added a comment -

          @olivier_trempe for this purpose upgrade to 1.50-beta-2 (experimental update center only) and define a Mercurial installation with the desired custom configuration (extension definition).

          Jesse Glick added a comment - @olivier_trempe for this purpose upgrade to 1.50-beta-2 (experimental update center only) and define a Mercurial installation with the desired custom configuration (extension definition).

          @jglick I upgraded to 1.50-beta-2. From what I understand, this does not solve my issue as environment variables set in slave configuration are still not used by the mercurial plugin. Thus I cannot rely on setting HGRCPATH in slaves configuration to use a specific hgrc on each slave machine.

          Olivier Trempe added a comment - @jglick I upgraded to 1.50-beta-2. From what I understand, this does not solve my issue as environment variables set in slave configuration are still not used by the mercurial plugin. Thus I cannot rely on setting HGRCPATH in slaves configuration to use a specific hgrc on each slave machine.

          Jesse Glick added a comment -

          I guess that would matter if you used a custom version of the largefiles extension, and this was in a different location on each slave. Normally to enable it you would simply use

          [extensions]
          largefiles =
          

          since it is a bundled extension.

          (%include syntax is not currently supported for the configuration field, though I think it could be with a bit of work.)

          Jesse Glick added a comment - I guess that would matter if you used a custom version of the largefiles extension, and this was in a different location on each slave. Normally to enable it you would simply use [extensions] largefiles = since it is a bundled extension. ( %include syntax is not currently supported for the configuration field, though I think it could be with a bit of work.)

          Jesse Glick added a comment -

          Oh and even if you do have a custom extension, you could always create a ZIP of a Mercurial installation containing it in the hgext directory and specify a ZIP download tool installer for the Jenkins definition of the installation. More cumbersome but would work.

          Jesse Glick added a comment - Oh and even if you do have a custom extension, you could always create a ZIP of a Mercurial installation containing it in the hgext directory and specify a ZIP download tool installer for the Jenkins definition of the installation. More cumbersome but would work.

          The use of largefiles extension was just an example to illustrate the problem.

          The actual hgrc file I want to use contains many other things: hooks, extensions, auth, many subpaths

          Olivier Trempe added a comment - The use of largefiles extension was just an example to illustrate the problem. The actual hgrc file I want to use contains many other things: hooks, extensions, auth, many subpaths

          The hgrc files are managed on every slaves with a configuration management tool. It is very easy to customize the content and its location. So being able to use HGRCPATH environment variable would help a lot for that matter.

          Olivier Trempe added a comment - The hgrc files are managed on every slaves with a configuration management tool. It is very easy to customize the content and its location. So being able to use HGRCPATH environment variable would help a lot for that matter.

          Jesse Glick added a comment -

          So support for %include $HGRCPATH would be helpful in your case.

          Anyway it sounds like your issue has nothing whatsoever to do with the issue originally reported here, which is about expansion of variables in a clone URL and the comparison done by the plugin between the attempted clone URL and the path reported in the workspace (which is done to ensure that you get a clean clone after switching repository location).

          Jesse Glick added a comment - So support for %include $HGRCPATH would be helpful in your case. Anyway it sounds like your issue has nothing whatsoever to do with the issue originally reported here, which is about expansion of variables in a clone URL and the comparison done by the plugin between the attempted clone URL and the path reported in the workspace (which is done to ensure that you get a clean clone after switching repository location).

          Yes it would be useful.

          Sorry for spamming this issue...

          Olivier Trempe added a comment - Yes it would be useful. Sorry for spamming this issue...

          Jesse Glick added a comment -

          Possibly fixed by https://github.com/jenkinsci/mercurial-plugin/pull/60 so (@nivecher) recheck in 1.51-beta-2.

          Jesse Glick added a comment - Possibly fixed by https://github.com/jenkinsci/mercurial-plugin/pull/60 so (@nivecher) recheck in 1.51-beta-2.

            jglick Jesse Glick
            nivecher Morgan Davis
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: