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

After migrating to another IP hyperlink in "Slaves in label" still refers to old value.

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • Debian 7, Jenkins 1.565

      So I have VM with Jenkins in production and I've cloned it to try some configuration.
      When I go to Job Configuration on clone, check "Restrict where this project can be run", and fill in label, I'm getting following: "Slaves in label: 2". It's OK, but hyperlink in word "label" still contains fqdn of production VM. Since all other links were transformed by Jenkins from fqdn of production to IP of clone, this was unexpected.
      And this could result in failure in production because moving from clone to prod. was too easy and might be noticed only by looking into address bar. Honestly, I don't do it that often.
      Example:
      I've had "jenkins.example.org" and clone has "192.168.0.15".
      So I will have page with address "http://192.168.0.15/job/test/configure", with "Slaves in label" refers to "http://jenkins.example.org/label/label-test" instead of "http://192.168.0.15/label/label-test"

          [JENKINS-23270] After migrating to another IP hyperlink in "Slaves in label" still refers to old value.

          I assumed you have cloned the global configuration without changing Jenkins URL in global config.

          Oliver Gondža added a comment - I assumed you have cloned the global configuration without changing Jenkins URL in global config.

          Yes, you're right.
          But look: I started new VM, Jenkins, logged in and saw all links now pointing to new VM IP. I thought it is all right.
          And then, suddenly, one link depends on system variable.
          I think, either all of them should depend on Jenkins URL, or no one.
          Or am I missing some logic in this exact behavior?

          Kirill Bucharsky added a comment - Yes, you're right. But look: I started new VM, Jenkins, logged in and saw all links now pointing to new VM IP. I thought it is all right. And then, suddenly, one link depends on system variable. I think, either all of them should depend on Jenkins URL, or no one. Or am I missing some logic in this exact behavior?

          Or am I missing some logic in this exact behavior?

          No, the link should be corrected.

          Oliver Gondža added a comment - Or am I missing some logic in this exact behavior? No, the link should be corrected.

          Oleg Nenashev added a comment -

          The built-in help provides the detailed explanation, why Jenkins needs the explicit configuration of "Jenkins URL"

          Oleg Nenashev added a comment - The built-in help provides the detailed explanation, why Jenkins needs the explicit configuration of "Jenkins URL"

          Actually, I believe this issue is valid. According to https://wiki.jenkins-ci.org/display/JENKINS/Hyperlinks+in+HTML, relative links should be used wherever possible. And it is possible in form validation handler. Needles to say it was me who introduced this in https://github.com/jenkinsci/jenkins/commit/f34ea92edeaf9cb7ff174a6974b950a8e13f97aa.

          Oliver Gondža added a comment - Actually, I believe this issue is valid. According to https://wiki.jenkins-ci.org/display/JENKINS/Hyperlinks+in+HTML , relative links should be used wherever possible. And it is possible in form validation handler. Needles to say it was me who introduced this in https://github.com/jenkinsci/jenkins/commit/f34ea92edeaf9cb7ff174a6974b950a8e13f97aa .

            Unassigned Unassigned
            doz10us Kirill Bucharsky
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: