parameter added by plugin during build not showing up in build's parameter list. Is there a better way?

189 views
Skip to first unread message

da3v

unread,
Aug 31, 2012, 1:03:56 PM8/31/12
to jenkin...@googlegroups.com

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  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 , I see that Kohsuke Kawaguchi "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

cjo

unread,
Aug 31, 2012, 2:12:56 PM8/31/12
to jenkin...@googlegroups.com
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;
    }
}


da3v

unread,
Sep 4, 2012, 11:15:21 AM9/4/12
to jenkin...@googlegroups.com
Thanks, this is a HUGE help!
Reply all
Reply to author
Forward
0 new messages