[
https://issues.jenkins-ci.org/browse/JENKINS-13552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162355#comment-162355
]
Marcel Huber commented on JENKINS-13552:
----------------------------------------
The reason behind this issue is the fact that configuring a jenkins job in the
means of using env variables is quite difficult because of the many checkboxes
and textboxes placed all over in jenkins.
*System Configuration*
I have the possibility to configure global - master node/systemwide options.
There I get the hint that node/slave specific settings might exist too. The
'Unset System Environment Variables' checkbox is really nice, I do not get
*any* clue what kind of variables might be set at this point nor do I have
control of enabling/disabling at variable level here.
-> a list of master variables injected from this point would clarify much I
think
*Node Configuration*
Again, I have the option to enable/disable preparing a job environment and
fairly the same options as at system level above but probably still have no
clue what impact to my job it might have.
-> a list of node specific variables injected from this point would clarify
again I think
-> at this point a comparison of variables/values against master would
potentially help to find out which variables I really need to redefine as they
differ from master.
*Job level configuration*
The complexity increases again as I now have the possibility to enable/disable
'Keep Jenkins Environment Variables' and 'Keep Jenkins Build Variables' but
have no clue what exactly I do unless I run the job several times and try to
build my own paper variable comparison matrix by using the fairly helpful 'env'
shell command which is the only tool I can use to inspect - at least on unix
like systems.
-> at this point I can spend hours reconfiguring the job including master/slave
node settings and build it again to see what changes in environment variable
settings I get.
*Black magic*
Finally there are parts of the system I might not have any control at all. For
example I can not redefine the WORKSPACE variable in a multi configuration job
using environment variables in such a way that I can get rid of having
($axislabel/$axislabelvalue)* appended anyhow. At least such an override - done
by using the cool groovy script feature - has no effect on the SCM checkout as
it still used the pre-override value :(
I really appreciate what you have done so far but if these things could be made
more transparent to the user it would be much easier to get a job correctly
configured and running in less cycles/time.
> Provide extended 'injected environment variables' view
> ------------------------------------------------------
>
> Key: JENKINS-13552
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13552
> Project: Jenkins
> Issue Type: New Feature
> Components: envinject
> Reporter: Marcel Huber
> Assignee: gbois
>
> Especially in multi configuration jobs and master/slave environments, it is
> sometimes difficult to examine where an injected value comes from and
> probably why it is different to our expectation.
> I guess a UI containing an env location matrix would help to figure out the
> origin of a value.
> Example:
> |Variable name | injected value | injected from | masters value |
> propertiesfile value | slave value | groovy script | ... |
> |HOME | /var/lib/jenins | slave | /home/jenkins | -- |
> /var/lib/jenkins | -- | ... |
> |...| | | | | | | |
> I could also think of such a matrix as a help for configuration when you
> don't actually know all parties potentially injecting values for a variable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
