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

Builds get triggered multiple times when the SCM URL contains variables that change on each node

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None

      The issue at hand is the following:

      Project contains and svn url of the form: $SVN_ROOT_PATH/trunk
      Each node sets $SVN_ROOT_PATH to the SVN mirror closer to the node location.

      This allows us to have fast checkouts etc.

      Problem now is that Jenkins seems to think that the master evaluated SVN URL is different than the workspace checkout path of a slave and triggers a new build.
      This happens until it happens that the slave that picks the build is using the same mirror as the master.

      Setting polling to master only (via the magic property) does not fix the issue since the problem is not polling but Jenkins trying to be smart and detecting that the workspace has a different SVN URL than the configuration.

      Not sure how to tackle this but I am having a look.

          [JENKINS-24554] Builds get triggered multiple times when the SCM URL contains variables that change on each node

          Alex Ouzounis added a comment - - edited

          I am looking if we can detect such a condition (by the presence of a variable in the project configuration svn url) and skip this check if that is true.

          Bug exists in subversionSCM: compareRemoteRevisionWith() lines 1360 - 1375

          Alex Ouzounis added a comment - - edited I am looking if we can detect such a condition (by the presence of a variable in the project configuration svn url) and skip this check if that is true. Bug exists in subversionSCM: compareRemoteRevisionWith() lines 1360 - 1375

          Daniel Beck added a comment -

          I am looking if we can detect such a condition (by the presence of a variable in the project configuration svn url) and skip this check if that is true.

          Are you absolutely sure that the only reason to use variables in the URL is this? Because I've often seen variables used, and never for this.

          Wouldn't routing (i.e. a network-based approach) be a better idea?

          Daniel Beck added a comment - I am looking if we can detect such a condition (by the presence of a variable in the project configuration svn url) and skip this check if that is true. Are you absolutely sure that the only reason to use variables in the URL is this? Because I've often seen variables used, and never for this. Wouldn't routing (i.e. a network-based approach) be a better idea?

          Alex Ouzounis added a comment -

          Indeed another way forward would be to use the same path on all nodes and setup a proxy or something on the physical machine the slave runs.
          The issue here is that setting up network routing for all nodes does not really scale so ideally the variables should work, and it does up to a point ;p

          since I do not care Jenkins detecting that the svn config url has changed and trigger a build I might just fork and delete those lines although I would prefer a solution in the original plugin

          Alex

          Alex Ouzounis added a comment - Indeed another way forward would be to use the same path on all nodes and setup a proxy or something on the physical machine the slave runs. The issue here is that setting up network routing for all nodes does not really scale so ideally the variables should work, and it does up to a point ;p since I do not care Jenkins detecting that the svn config url has changed and trigger a build I might just fork and delete those lines although I would prefer a solution in the original plugin Alex

          Alex Ouzounis added a comment -

          It seems to me that this "feature" of detecting a configuration change or mismatch between config and last build during polling is not ideal.

          Maybe trying to resolve the master "raw" svn url using the environment of the last build is better than just looking for "$" and skipping the check altogether ?

          Alex

          Alex Ouzounis added a comment - It seems to me that this "feature" of detecting a configuration change or mismatch between config and last build during polling is not ideal. Maybe trying to resolve the master "raw" svn url using the environment of the last build is better than just looking for "$" and skipping the check altogether ? Alex

          Alex Ouzounis added a comment - - edited

          Created pull request where if property hudson.scm.SubversionSCM.disableTriggerOnScmConfigMismatch is set to true, the comparison is skipped. Default is true to maintain existing behaviour.

          https://github.com/jenkinsci/subversion-plugin/pull/95

          Alex Ouzounis added a comment - - edited Created pull request where if property hudson.scm.SubversionSCM.disableTriggerOnScmConfigMismatch is set to true, the comparison is skipped. Default is true to maintain existing behaviour. https://github.com/jenkinsci/subversion-plugin/pull/95

          Alex Ouzounis added a comment -

          My interpretation was slightly wrong.
          Its not the master and a slave being compared but its lastBuild and lastCompletetedBuild. While a build is running these two are not the same and if those two builds were executed in two different slaves with two different environments then the comparison is not fair.
          I updated the pull request such that when the two urls are compared the environment from lastBuild is used for both builds. That way if svn related vars are different, that will not affect the result of the comparison

          Alex Ouzounis added a comment - My interpretation was slightly wrong. Its not the master and a slave being compared but its lastBuild and lastCompletetedBuild. While a build is running these two are not the same and if those two builds were executed in two different slaves with two different environments then the comparison is not fair. I updated the pull request such that when the two urls are compared the environment from lastBuild is used for both builds. That way if svn related vars are different, that will not affect the result of the comparison

          Alex Ouzounis added a comment -

          Pull request: https://github.com/jenkinsci/subversion-plugin/commit/6496d7fa3623408a7af571601deac75c8cc29dcb
          When comparing builds make sure the environment used is based on the system env vars otherwise the comparison is not fair. Use the incoming build's system environment variables.

          Please review and merge

          Alex Ouzounis added a comment - Pull request: https://github.com/jenkinsci/subversion-plugin/commit/6496d7fa3623408a7af571601deac75c8cc29dcb When comparing builds make sure the environment used is based on the system env vars otherwise the comparison is not fair. Use the incoming build's system environment variables. Please review and merge

            Unassigned Unassigned
            alex_ouzounis Alex Ouzounis
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: