While debugging other plugins that were using a ParameterAction to add
variables to the build, and then using build.getAction(ParametersAction.class)
to remove it later in the build, caused problems if the job was started
from an upstream passing parameters.
This is because build.getAction(ParametersAction.class) only returns the
first ParametersAction
so you should use
public <T extends Action> List<T> getActions(Class<T> type)
from AbstractBuild [1]
Also there is a UI issue that if there are multiple ParametersActions on
the build, only the first one gets shown when going to the link, even
though there are multiple entries on the left hand list.
Basically in your plugin,
You would implement a class to perform this Action and attach it to the
build using
build.getActions.add(new MyPluginHiddenParametersAction("test_value"));
example class: extends InvisibleAction[2] so it does not show in the UI as
you mentioned in the other thread.
with a single fixed Env Variable this can be extended to whatever you need.
(UNTESTED and quite possibly missing something)
import hudson.model.InvisibleAction;
import hudson.model.EnvironmentContributingAction;
class MyPluginHiddenParametersAction extends InvisibleAction implements
EnvironmentContributingAction {
private String value;
public MyPluginHiddenParametersAction(String value){
this.value = value;
}
/* from EnvironmentContributingAction */
public void buildEnvVars(AbstractBuild<?,?> build, EnvVars env) {
env.put("MYPLUGIN_NAME", value);
}
}
Having your own class will also allow to find it in all of the different
places you need to use it, if you are implementing a builder, publisher and
other extension points.
If you want all of the ParameterAction functionality you could extend that,
and provide the constructors you need passing to the superclass.
And then to hide it in the UI override and return null or empty string for
the getURL, getIcon, and getDisplayName. [3]
example class:
import hudson.model.InvisibleAction;
import hudson.model.EnvironmentContributingAction;
class MyPluginHiddenParametersAction extends ParametersAction {
public MyPluginHiddenParametersAction(List<ParameterValue> parameters) {
super(parameters);
}
public MyPluginHiddenParametersAction(ParameterValue... parameters) {
super(Arrays.asList(parameters));
}
@Override
public String getDisplayName() {
return "";
}
@Override
public String getIconFileName() {
return null;
}
@Override
public String getUrlName() {
return null;
}
}
[1] http://javadoc.jenkins-ci.org/index.html?hudson/model/AbstractBuild.html
[2]
http://javadoc.jenkins-ci.org/index.html?hudson/model/InvisibleAction.html
[3] http://javadoc.jenkins-ci.org/index.html?hudson/model/Action.html
On Friday, August 31, 2012 6:03:56 PM UTC+1, da3v wrote:
>
> Hi,
>
> I am trying to write a plugin that will be called several times during a
> build with different options set. During the first call, I would like to
> set several parameters that will be used during subsequent calls. In this
> thread<https://groups.google.com/forum/?fromgroups=#!searchin/jenkinsci-dev/parametersaction/jenkinsci-dev/-WcPTB6bR9Y/h0maKoW0RoMJ>
> I
> found the helpful suggestion to use
>
>
> build.addAction(new ParametersAction(new
> StringParameterValue("MY_NEW_PARAM","my_new_param_value")));
>
>
> This does add MY_NEW_PARAM=my_new_param_value to the environment, and I
> can see it via
>
> EnvVars env=new EnvVars();
>
> env = build.getEnvironment(launcher.getListener());
>
> System.out.println(env.toString());
>
>
> However, I do not see it in the build's parameters.
>
> ParametersAction parameters =
> build.getAction(ParametersAction.class);
>
> List<ParameterValue> paramList=parameters.getParameters();
>
> System.out.println(paramList.toString());
>
>
> During subsequent calls to my plugin during a build, I still see the new
> param in the environment, but do not see it in the parameter list, and do
> not see it in the parameters summary when the build is done.
>
>
> Another approach:
>
> In this
> thread<http://jenkins.361315.n4.nabble.com/Plugin-dev-Builder-and-the-exporting-of-environment-variables-tt394181.html#a394182>
> ,
> I see that Kohsuke
> Kawaguchi<http://jenkins.361315.n4.nabble.com/template/NamlServlet.jtp?macro=user_nodes&user=120869>
> "added EnvironmentContributingAction as a generalization of
> ParametersAction, so that you can contribute environment variables
> from arbitrary Actions."
>
> However I have not had much luck finding many clues about how to implement
> it.
>
> I tried this:
>
> EnvVars myenv=new EnvVars();
>
> myenv.put("TEST_PARAM", "PARAM_VALUE");
>
> EnvironmentContributingAction
> ea=build.getAction(EnvironmentContributingAction.class);
>
> ea.buildEnvVars(build, myenv);
>
> System.out.println(myenv.toString());
>
> env=build.getEnvironment(launcher.getListener());
>
> System.out.println(env.toString());
>
>
> And it looks like ea.buildEnvVars(build, myenv); does add the build's
> params to myenv, but not the other way around, which is what I was looking
> for.
>
> I'm not a java expert, I'm just a build guy who is desperately trying to
> get Jenkins to play nice with some of our proprietary tools so that I can
> convince our team to adopt Jenkins, so please go easy on me. A short code
> snippet would be a huge, huge help.
>
> Thanks,
>
> -Dave
>
>
