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

Can't use environment variables like JENKINS_URL、JOB_URL、BUILD_URL in a new jenkins before it's save-button which is in system settings is clicked

    Details

    • Similar Issues:

      Description

      when I start to use a new Jenkins, some environment variables like JENKINS_URL、JOB_URL、BUILD_URL can't be used.But when I click the save-button in system settings ,those environment variables works.So i doubt is it right?

        Attachments

          Issue Links

            Activity

            Hide
            slide_o_mix Alex Earl added a comment -

            Jenkins currently looks at the explicitly configured location information, and if that doesn't exist, it tries to use the current StaplerRequest. In the case of a job using the variables, there is no StaplerRequest, so there is no fallback to getting this information.

            Show
            slide_o_mix Alex Earl added a comment - Jenkins currently looks at the explicitly configured location information, and if that doesn't exist, it tries to use the current StaplerRequest. In the case of a job using the variables, there is no StaplerRequest, so there is no fallback to getting this information.
            Hide
            javiplx Javier Palacios added a comment - - edited

            I've also hit this issue. My case is running acceptance checks for the gitlab-hook plugin. The plugin submits the url to gitlab to be stored there, and it is one of the things I want to verify on acceptance tests.
            I run them on TravisCI, and the only BUILD_* variables that are set there are
            BUILD_DISPLAY_NAME='#1'
            BUILD_ID='1'
            BUILD_NUMBER='1'
            BUILD_TAG='jenkins-multiscm_master-1'

            Edit: most of the projects are created by the plugin from other projects, and the config.xml I setup before firing the jenkins instance can be seen at github repo

            Show
            javiplx Javier Palacios added a comment - - edited I've also hit this issue. My case is running acceptance checks for the gitlab-hook plugin. The plugin submits the url to gitlab to be stored there, and it is one of the things I want to verify on acceptance tests. I run them on TravisCI, and the only BUILD_* variables that are set there are BUILD_DISPLAY_NAME='#1' BUILD_ID='1' BUILD_NUMBER='1' BUILD_TAG='jenkins-multiscm_master-1' Edit: most of the projects are created by the plugin from other projects, and the config.xml I setup before firing the jenkins instance can be seen at github repo
            Hide
            javiplx Javier Palacios added a comment -

            After looking at some other issues, and my live jenkins machine, I've tested adding jenkins.model.JenkinsLocationConfiguration.xml at JENKINS_HOME, and after that the BUILD_URL is appearing on environment.

            Show
            javiplx Javier Palacios added a comment - After looking at some other issues, and my live jenkins machine, I've tested adding jenkins.model.JenkinsLocationConfiguration.xml at JENKINS_HOME, and after that the BUILD_URL is appearing on environment.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Javier Palacios
            Path:
            work/jenkins.model.JenkinsLocationConfiguration.xml
            http://jenkins-ci.org/commit/gitlab-hook-plugin/1bb034f5d5c7a449b733758af056441668e75853
            Log:
            Add jenkins_url variable (JENKINS-28466)

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Javier Palacios Path: work/jenkins.model.JenkinsLocationConfiguration.xml http://jenkins-ci.org/commit/gitlab-hook-plugin/1bb034f5d5c7a449b733758af056441668e75853 Log: Add jenkins_url variable ( JENKINS-28466 )
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Javier Palacios
            Path:
            work/jenkins.model.JenkinsLocationConfiguration.xml
            http://jenkins-ci.org/commit/gitlab-hook-plugin/25d0c62f1028aabd4aef460dfea5fe275817f242
            Log:
            Add jenkins_url variable (JENKINS-28466)

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Javier Palacios Path: work/jenkins.model.JenkinsLocationConfiguration.xml http://jenkins-ci.org/commit/gitlab-hook-plugin/25d0c62f1028aabd4aef460dfea5fe275817f242 Log: Add jenkins_url variable ( JENKINS-28466 )
            Hide
            ioannis Ioannis Moutsatsos added a comment -

            I've hit this bug while trying to create a quick installation of Jenkins for testing jobs with minimal Jenkins configuration.

            The idea is to get to a runnable job as quickly as possible from zero jenkins infrastructure.
            I chekcout preconfigured SCM folders with content that correspond to standard Jenkins folders (suchs as jobs, userContent, plugins, scriptler) and then drop a jenkins.war in the root folder. I then start a jenkins server from the command line using java -jar jenkins.war

            I get a running instance with minimal installation but some of my jobs that depend on the missing env variables now fail. Have to go into 'Configure System' and save before these variables are set in the build environment again. Fixing this bug would help eliminate this extra step.

            Show
            ioannis Ioannis Moutsatsos added a comment - I've hit this bug while trying to create a quick installation of Jenkins for testing jobs with minimal Jenkins configuration. The idea is to get to a runnable job as quickly as possible from zero jenkins infrastructure. I chekcout preconfigured SCM folders with content that correspond to standard Jenkins folders (suchs as jobs, userContent, plugins, scriptler) and then drop a jenkins.war in the root folder. I then start a jenkins server from the command line using java -jar jenkins.war I get a running instance with minimal installation but some of my jobs that depend on the missing env variables now fail. Have to go into 'Configure System' and save before these variables are set in the build environment again. Fixing this bug would help eliminate this extra step.
            Hide
            danielbeck Daniel Beck added a comment - - edited

            TBH I see no bug here. The Jenkins URL isn't configured, so URL cannot be provided (outside a context in which the ServletRequest would be available).

            If this were "fixed", it would just result in the bug "Jenkins provides useless URLs to http://localhost:8080 in environment variables", so not exactly moving anything ahead.

            Show
            danielbeck Daniel Beck added a comment - - edited TBH I see no bug here. The Jenkins URL isn't configured, so URL cannot be provided (outside a context in which the ServletRequest would be available). If this were "fixed", it would just result in the bug "Jenkins provides useless URLs to http://localhost:8080 in environment variables", so not exactly moving anything ahead.
            Hide
            javiplx Javier Palacios added a comment -

            It is a real bug Daniel Beck, because it happens on a running jenkins instance. So http://localhost:8080 is not useless but the real url. Not sure about the case for ioannis, but in mine was for running acceptance tests so localhost is not a problem, and I'm not sure if that is the real default or is 0.0.0.0

            Show
            javiplx Javier Palacios added a comment - It is a real bug Daniel Beck , because it happens on a running jenkins instance. So http://localhost:8080 is not useless but the real url. Not sure about the case for ioannis, but in mine was for running acceptance tests so localhost is not a problem, and I'm not sure if that is the real default or is 0.0.0.0
            Hide
            markewaite Mark Waite added a comment -

            For the use case where you are starting a Jenkins instance (acceptance testing) with pre-defined jobs or users or other configuration, you can resolve it as described by Javier Palacios in the earlier comment

            Show
            markewaite Mark Waite added a comment - For the use case where you are starting a Jenkins instance (acceptance testing) with pre-defined jobs or users or other configuration, you can resolve it as described by Javier Palacios in the earlier comment
            Hide
            ioannis Ioannis Moutsatsos added a comment - - edited

            Yes, the workaround by Javier Palacios works and its great. I also tend to disagree with Daniel Beck that setting BUILD_URL to http://localhost:8080 is useless! It is causing issues and fails my jobs that are trying to use a null BUILD_URL. If http://localhost:8080 is what appear in the global configuration it should be reflected in a corresponding env variable. However, I do admit that mine is a special case. A quick setup of a Jenkins environment for demo purposes. In my case the less configuration the better. This would not be my production environment where a real URL would appear for Jenkisn_URL. By the way, I think that my use case is very similar to that of Javier althought for totally differnt end goals.Best regards to all for the useful discussion and workaround suggestion!

            Show
            ioannis Ioannis Moutsatsos added a comment - - edited Yes, the workaround by Javier Palacios works and its great. I also tend to disagree with Daniel Beck that setting BUILD_URL to http://localhost:8080 is useless! It is causing issues and fails my jobs that are trying to use a null BUILD_URL. If http://localhost:8080 is what appear in the global configuration it should be reflected in a corresponding env variable. However, I do admit that mine is a special case. A quick setup of a Jenkins environment for demo purposes. In my case the less configuration the better. This would not be my production environment where a real URL would appear for Jenkisn_URL. By the way, I think that my use case is very similar to that of Javier althought for totally differnt end goals.Best regards to all for the useful discussion and workaround suggestion!
            Hide
            laffoyb Barry Laffoy added a comment -

            I'm also affected by this bug while trying to set up a Jenkins instance for development, testing, and acceptance testing.

            While using the official jenkinsci/docker image, the Jenkins instance in my container has a value visible at the page myjenkins.mycompany.com:8080/configure under "Jenkins Location" -> "Jenkins URL" of http://myjenkins.mycompany.com:8080. This value is present immediately after provisioning the container.

            However, this value is not accessible to jobs unless you first open that page and click save.

            Creating `jenkins.model.JenkinsLocationConfiguration.xml` as part of the provisioning of the instance is an acceptable workaround. But it is a workaround to a bug.

            I'm baffled as to how anyone would say that this is not a bug.

            Show
            laffoyb Barry Laffoy added a comment - I'm also affected by this bug while trying to set up a Jenkins instance for development, testing, and acceptance testing. While using the official jenkinsci/docker image, the Jenkins instance in my container has a value visible at the page myjenkins.mycompany.com:8080/configure under "Jenkins Location" -> "Jenkins URL" of http://myjenkins.mycompany.com:8080 . This value is present immediately after provisioning the container. However, this value is not accessible to jobs unless you first open that page and click save. Creating `jenkins.model.JenkinsLocationConfiguration.xml` as part of the provisioning of the instance is an acceptable workaround. But it is a workaround to a bug. I'm baffled as to how anyone would say that this is not a bug.
            Hide
            danielbeck Daniel Beck added a comment -

            This value is present immediately after provisioning the container.

            … and it's based on the request URL that is only available in the context of a request. If Jenkins is running on a different port, or you access it with a different host name, those would be reflected here.

            You opening the config page: In an HTTP request context.
            A build running: Not in an HTTP request context.

            So your argument based on this form value doesn't make sense.

            FWIW just setting 'localhost:8080' as the default would be wrong for pretty much all deployments to production, and not allow the automatism of filling the Configure System form field with a real default.

            Show
            danielbeck Daniel Beck added a comment - This value is present immediately after provisioning the container. … and it's based on the request URL that is only available in the context of a request. If Jenkins is running on a different port, or you access it with a different host name, those would be reflected here. You opening the config page: In an HTTP request context. A build running: Not in an HTTP request context. So your argument based on this form value doesn't make sense. FWIW just setting 'localhost:8080' as the default would be wrong for pretty much all deployments to production, and not allow the automatism of filling the Configure System form field with a real default.
            Hide
            laffoyb Barry Laffoy added a comment - - edited

            Okay, that actually makes a lot more sense to me. I didn't realise that the context from which it was populating the field in the form was the http request to open the form.

            I withdraw my assertion that this is definitely a bug.

            It just gets frustrating that a tool like Jenkins which is designed for automation, fights me every step of the way when I try to build automation around it.

            P.S. Thanks for the quick response

            Show
            laffoyb Barry Laffoy added a comment - - edited Okay, that actually makes a lot more sense to me. I didn't realise that the context from which it was populating the field in the form was the http request to open the form. I withdraw my assertion that this is definitely a bug. It just gets frustrating that a tool like Jenkins which is designed for automation, fights me every step of the way when I try to build automation around it. P.S. Thanks for the quick response
            Hide
            slide_o_mix Alex Earl added a comment -

            It might be useful for you to post to the users mailing list with some issues you've been having. I know there are lots of people who are automating the setup and configuration of Jenkins, so maybe there is someone who can point you to some existing blogs or similar that have information you might find useful.

            Show
            slide_o_mix Alex Earl added a comment - It might be useful for you to post to the users mailing list with some issues you've been having. I know there are lots of people who are automating the setup and configuration of Jenkins, so maybe there is someone who can point you to some existing blogs or similar that have information you might find useful.
            Hide
            laffoyb Barry Laffoy added a comment - - edited

            Another work-around copy a groovy script to /usr/share/jenkins/ref/init.groovy.d/ before starting the Jenkins process, with the environment variable _JENKINS_URL set to the desired value:

            import jenkins.model.JenkinsLocationConfiguration
            def jlc = jenkins.model.JenkinsLocationConfiguration.get()
            def url = System.getenv('_JENKINS_URL')
            jlc.setUrl(url)
            

            Alex Earll Thanks for the suggestion, I've been over there quite a bit and found some helpful info. The jenkinsci/docker image is the best resource I've found to ease this pain, but it still needs a lot of end-user work in order to fit with existing Jenkins deployments. I just find it frustrating that a tool so popular with a community obsessed with automation almost seems to have been designed purposefully to thwart any attempt at automation.

            Show
            laffoyb Barry Laffoy added a comment - - edited Another work-around copy a groovy script to /usr/share/jenkins/ref/init.groovy.d/ before starting the Jenkins process, with the environment variable _JENKINS_URL set to the desired value: import jenkins.model.JenkinsLocationConfiguration def jlc = jenkins.model.JenkinsLocationConfiguration.get() def url = System .getenv( '_JENKINS_URL' ) jlc.setUrl(url) Alex Earl l Thanks for the suggestion, I've been over there quite a bit and found some helpful info. The jenkinsci/docker image is the best resource I've found to ease this pain, but it still needs a lot of end-user work in order to fit with existing Jenkins deployments. I just find it frustrating that a tool so popular with a community obsessed with automation almost seems to have been designed purposefully to thwart any attempt at automation.
            Hide
            slide_o_mix Alex Earl added a comment -

            Please file issues on the things you run into, it won't get better if people don't tell developers what issues they have.

            Show
            slide_o_mix Alex Earl added a comment - Please file issues on the things you run into, it won't get better if people don't tell developers what issues they have.
            Hide
            laffoyb Barry Laffoy added a comment -

            Alex Earl, I will bear that in mind. It's likely that every issue I want to file can be summarised as "Why can't I configure <something> with an environment variable and/or a configuration file to aid automation?"

            On this topic, even if the current behaviour of JENKINS_URL isn't being considered a bug, I think that the fact that the config settings screen is actively misleading to users should be considered one. Either the field should not be populated from the HTTP context of the request, or it should be clearly marked as a suggestion that has not actually been added to Jenkins' configuration.

            Show
            laffoyb Barry Laffoy added a comment - Alex Earl , I will bear that in mind. It's likely that every issue I want to file can be summarised as "Why can't I configure <something> with an environment variable and/or a configuration file to aid automation?" On this topic, even if the current behaviour of JENKINS_URL isn't being considered a bug, I think that the fact that the config settings screen is actively misleading to users should be considered one. Either the field should not be populated from the HTTP context of the request, or it should be clearly marked as a suggestion that has not actually been added to Jenkins' configuration.
            Hide
            cweaver Chris Weaver added a comment -

            I have the same problem for the same reasons (fully automating a Jenkins install) and I still don't understand how this is not a bug. I see a configuration page that is full of configuration, but only half of it is actually in the system until I click "Save". So how can I trust the information on this page? Or any page?

            There must be a better solution than "go through every configuration page clicking Save as soon as Jenkins comes up".

            Show
            cweaver Chris Weaver added a comment - I have the same problem for the same reasons (fully automating a Jenkins install) and I still don't understand how this is not a bug. I see a configuration page that is full of configuration, but only half of it is actually in the system until I click "Save". So how can I trust the information on this page? Or any page? There must be a better solution than "go through every configuration page clicking Save as soon as Jenkins comes up".
            Hide
            markewaite Mark Waite added a comment -

            Chris Weaver, no one suggested that anyone needs to

            go through every configuration page clicking Save as soon as Jenkins comes up

            The JENKINS_URL needs to be configured before it can be returned. It is configured through the XML file jenkins.model.JenkinsLocationConfiguration.xml or through the groovy script that Barry Laffoy provided in an earlier comment.

            I use the XML file in a private copy of my Docker image. It has worked very well for me automating deployment to multiple machines in multiple environments.

            Show
            markewaite Mark Waite added a comment - Chris Weaver , no one suggested that anyone needs to go through every configuration page clicking Save as soon as Jenkins comes up The JENKINS_URL needs to be configured before it can be returned. It is configured through the XML file jenkins.model.JenkinsLocationConfiguration.xml or through the groovy script that Barry Laffoy provided in an earlier comment . I use the XML file in a private copy of my Docker image . It has worked very well for me automating deployment to multiple machines in multiple environments.
            Hide
            chahal Pardeep Chahal added a comment - - edited

            We struggled for two days to find out this issue. Thanks for the help. Our Jenkins version is 2.85 and I am not sure if this issue works fine in older versions or not. 

            To replicate and fix this issue, please follow the below steps:

            1. Jenkins_URL or Jenkins parameters values must be coming null when you launch a fresh instance of Jenkins and trying to trigger some automation jobs, which uses environment variables. 
            2. To fix issue manually, Go to Manage Jenkins -> Configure System -> Save settings (without making any change). This should fix the issue if you are doing Jenkins configuration manually.
            3. To fix it during installation, follow steps mentioned by Mark Waite
            4. Create JENKINS_HOME/data/jenkins.model.JenkinsLocationConfiguration.xml and add below contents
            5. <?xml version='1.0' encoding='UTF-8'?>

            <jenkins.model.JenkinsLocationConfiguration>  <adminAddress>address not configured yet <nobody@nowhere></adminAddress>  <jenkinsUrl>JENKINS_URL_VALUE/</jenkinsUrl></jenkins.model.JenkinsLocationConfiguration>

            Show
            chahal Pardeep Chahal added a comment - - edited We struggled for two days to find out this issue. Thanks for the help. Our Jenkins version is 2.85 and I am not sure if this issue works fine in older versions or not.  To replicate and fix this issue, please follow the below steps: Jenkins_URL or Jenkins parameters values must be coming null when you launch a fresh instance of Jenkins and trying to trigger some automation jobs, which uses environment variables.  To fix issue manually, Go to Manage Jenkins -> Configure System -> Save settings (without making any change). This should fix the issue if you are doing Jenkins configuration manually. To fix it during installation, follow steps mentioned by Mark Waite .  Create JENKINS_HOME/data/jenkins.model.JenkinsLocationConfiguration.xml and add below contents <?xml version='1.0' encoding='UTF-8'?> <jenkins.model.JenkinsLocationConfiguration>   <adminAddress>address not configured yet <nobody@nowhere></adminAddress>   <jenkinsUrl>JENKINS_URL_VALUE/</jenkinsUrl> </jenkins.model.JenkinsLocationConfiguration>
            Hide
            danielbeck Daniel Beck added a comment -

            Fix in progress (admin monitor if it's unset, and adding it to the setup wizard) in the context of JENKINS-31661 so resolving as duplicate. The issues are related enough.

            Show
            danielbeck Daniel Beck added a comment - Fix in progress (admin monitor if it's unset, and adding it to the setup wizard) in the context of JENKINS-31661 so resolving as duplicate. The issues are related enough.

              People

              • Assignee:
                Unassigned
                Reporter:
                hz_tc liu yecheng
              • Votes:
                3 Vote for this issue
                Watchers:
                12 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: