0.21 fixed the problem. Thanks!
There is a tiny issue though, I defined the following in a .properties file:
MAILING_LIST_DEV=d...@company.com
MAILING_LIST_PM=p...@company.com
MAILING_LIST_RELEASE_NOTES=$MAILING_LIST_PM,$MAILING_LIST_DEV
If I inject this properties file directly through envinject plugin, the
variable MAILING_LIST_RELEASE_NOTES is correctly populated.But this
seems to be not the case with shared-objects + envinject plugin as you
described, the variable MAILING_LIST_RELEASE_NOTES is empty, the log reads:
[SharedObject] - Injecting shared objects as environment variables
[SharedObject] - Trying to retrieve a properties file through the url
valuehttp://compny.com/config/email/mailing_lists.properties
<http://subversion.berlin.strato.de/svn/jenkins/trunk/extensions/config/email/mailing_lists.properties>
associated to the shared object with the name Global Mailing List.
[EnvInject] - Unset unresolved 'MAILING_LIST_RELEASE_NOTES' variable.
Does the shared-objects plugin expand the variables a different way as
envinject plugin?
On 27.03.2012 22:33, Grégory Boissinot wrote:
Sorry, it was a regression.
Fixed in shared-objects plugin 0.21
On Mon, Mar 26, 2012 at 10:17 PM, John Vacz
<mailing.list.collect...@googlemail.com
<mailto:mailing.list.collect...@googlemail.com>> wrote:
Sorry, forgot to say, that the redirection on save button works.
The errors are only present in log file, no error messages on web
pages, but the objects are not saved.
On 25.03.2012 16 <tel:25.03.2012%2016>:02, Grégory Boissinot wrote:
It should be fix with SharedObjects plugin 0.20.
On Fri, Mar 23, 2012 at 7:13 AM, John Vacz
<mailing.list.collect...@googlemail.com
<mailto:mailing.list.collect...@googlemail.com>> wrote:
I have form submission problem on the shared objects
configure page when I access Jenkins through a local proxy
(ssl tunneling). I got a "server not found" page when I
click the "save" button, Jenkins was trying to
submit/redirect to https://real-server-name/jenkins//manage,
instead of (my guess) https://my-local-proxy/jenkins/manage.
Is there any way to get around this? I tried lynx/w3m on the
remote server, but they seem to have difficulties dealing
with the "drop down button" gadget.
On 18.03.2012 22:51, Grégory Boissinot wrote:
Thanks for testing EnvInject plugin.
EnvInject is aimed at managing environment variables.
For your need, you can use the Shared Objects plugin.
It's a complement to the EnvInject plugin. It enables you to
share objects in your environment (such as in your case a
properties files through an URL) and inject its content as
environment variables with the EnvInject plugin.
You define your shared objects in the global Jenkins
configuration (>Manage Jenkins> Shared Objects) and check
'Propagate shared objects' in the 'Prepare an environment
for the job run' section.
Shared objects will be computed dynamically and the results
will be injected as environment variables for each job build.
https://wiki.jenkins-ci.org/display/JENKINS/SharedObjects+Plugin
On Fri, Mar 16, 2012 at 10:43 AM, John Vacz
<mailing.list.collect...@googlemail.com
<mailto:mailing.list.collect...@googlemail.com>> wrote:
Can EnvInject plugin inject enviroment variables defined
in .properties file from a URL? I tried but it did not
work. Have i missed something obvious?
Our particular use case is that we need to inject some
mail address lists as environment variables to be used
by Email-ext plugin, and it would be very handy if we
can just inject those variables directly from a http
server (or our anonymous SVN in this particular case).
Meanwhile I add a shell script to download the
.properties file and then use EnvInject to inject them.
Furthermore, the variables are actually "global", it
would be great if we do not need to inject them in every
job, but globally in Jenkins. I noticed that in Jenkins
configure screen, there is a "Prepare jobs environment"
section (provided by EnvInject?), it seems that one can
inject viarables from a file with absolute path. But
have some concerns: a) this injection is rather
"static", as the help stated "You must restart the node
(master/slave) for the consideration of this property",
that means the variables cannot be changed on the fly (I
did not get a chance to test this, so I might be wrong);
b) I am not sure if this injection is transparent in a
master-slave setting.
Any suggestion is appreciated.
