-
Bug
-
Resolution: Duplicate
-
Major
-
Jenkins ver. 1.592
-
Powered by SuggestiMate
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?
- configure.JPG
- 28 kB
- result.JPG
- 29 kB
[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
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
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.
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)
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)
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.
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.
It is a real bug danielbeck, 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
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 javiplx in the earlier comment
Yes, the workaround by javiplx works and its great. I also tend to disagree with danielbeck 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!
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.
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.
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
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.
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)
slide_o_mixl 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.
Please file issues on the things you run into, it won't get better if people don't tell developers what issues they have.
slide_o_mix, 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.
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".
cweaver, 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 laffoyb 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.
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 markewaite .
- 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>
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.
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.