[
https://issues.jenkins-ci.org/browse/JENKINS-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163013#comment-163013
]
bogdaniosif commented on JENKINS-10899:
---------------------------------------
The major point you're making is I should store the settings in a file in
source control (VCS) and edit it via just like any other source file. My strong
counterargument is that I'm not asking this feature for those kind of settings.
I'm asking it for settings that do not belong in source control and need to
reside in configuration files located on the build server. I think we can agree
that such settings exist or otherwise Jenkins would by default suck all its XML
files from some sort of VCS instead of storing them on master's file system.
Think of a job that needs to connect to a custom VCS not supported by a Jenkins
plugin. Before a build for this job can retrieve any file from VCS it needs to
know connection details to the VCS, settings like a machine name, an URI, a
user name, a password, etc. I currently store such settings in a job's SetEnv's
config section so that I can see / change them via Jenkins' web ui for job
config (I will upgrade to EnvInject eventually anyway but it would be the same
thing for the purpose of this example).
The problem I have is that out of ~60 jobs on my build server, only groups of
~5 jobs use the same set of values for the settings I described above. So I'm
stuck with choosing to either write those values in a separate file for each
group of jobs and store these files on the build server OR copy/paste those
values in each job's SetEnv config section.
Either way I have to make an uncomfortable trade off. The copy/paste is
terrible because it creates redundant information that is hard to maintain.
With files I avoid this problem but I make the setting values obscure because
they are not visible in a job's config web ui.
Bottom line is that in this scenario, EnvInject is exactly the same as SetEnv +
Envfile and I hoped to get more than the sum of those parts out of EnvInject.
If you still feel the same way I'll accept your resolution and won't argue
about this feature anymore.
> Add the ability to show/edit from a job's configuration UI, a properties file
> containing env vars to be set by envinject
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: JENKINS-10899
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10899
> Project: Jenkins
> Issue Type: New Feature
> Components: envinject
> Reporter: bogdaniosif
> Assignee: Gregory Boissinot
>
> When env vars to be set by envinject are stored in a properties file, the
> following problem arises from a job's admin perspective: How is the file
> viewed/edited? The problem is bigger when the file is not coming from SCM,
> instead it just sits permanently in some location on the build server, e.g.
> in the same folder as the job's config.xml
> _*Feature Request:*_ Add to envinject the ability to show/edit in the job's
> configuration UI the content of a file containing env vars to be set. If it's
> possible, show/edit the content inline in the configuration page.
--
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
