EnvironmentContributingAction.buildEnvVars doesn't work

[sohl]

I'm using Saltstack plugin (https://github.com/jenkinsci/saltstack-plugin) in the pipeline. The plugin has an option to return output into SALTBUILDOUTPUT variable.

Although the plugin is not listed as pipeline compatible, it nevertheless works i.e. I'm able to run it using pipeline:

-----------------------------------------

node {

  salt authtype: 'pam', clientInterface: local(arguments: 'xxx', blockbuild: true, function: 'grains.get', target: 'atarget', targetType: 'glob'), credentialsId: '497b...', saveEnvVar: true, servername: 'http://172....'

println("SALTBUILDOUTPUT 1 = ${env.SALTBUILDOUTPUT}")

printf("SALTBUILDOUTPUT 3 = %s\n", env)

}

-----------------------------------------

The output:

-----------------------------------------

Running jid: 20170215152138504719

....

SALTBUILDOUTPUT 1 = null

SALTBUILDOUTPUT 3 = org.jenkinsci.plugins.workflow.cps.EnvActionImpl@1765f04e

...

-----------------------------------------

The plugin uses a standard method to set the variable by implementing "EnvironmentContributingAction.buildEnvVars" in "class PublishEnvVarAction extends InvisibleAction implements EnvironmentContributingAction".

Here is a snippet where it is called:

-----------------------------------------

public boolean perform(Run build,...) {

...

        if (saveEnvVar) {

            build.addAction(new PublishEnvVarAction("SALTBUILDOUTPUT", returnArray.toString()));

            build.getEnvironment(listener);

        }

...

}

------------------------------------------

I ran the plugin in the debugger and attest the snippet above was called as expected. 

On the other hand 'buildEnvVars' has never been called i.e. the breakpoint was never hit. Consequently the SALTBUILDOUTPUT remained NULL.

-----------------------------------------

I used a few versions of Jenkins while debugging including one built from Git (2.47-SNAPSHOT)

I also built the Saltstack plugin from sources with parent "org.jenkins-ci.plugins/plugin/2.20". Note that plugin has an obvious bug. It tries to readdress returnArray parameter within the scope of the called method, so that after the call returns all the information in returnArray is lost. I fixed the bug and the job returns output OK i.e. "returnArray.toString()" above returns information that can be seen in the debugger and is also printed by Jenkins into the log.

I suspect that some changes in Jenkins API rendered "EnvironmentContributingAction.buildEnvVars" useless. This is NOT a Saltstack plugin problem.

Please, help with resolving this.

[Jesse Glick]

On Thu, Feb 16, 2017 at 2:53 PM, sohl <mahr...@gmail.com> wrote:
> The plugin uses a standard method to set the variable by implementing
> "EnvironmentContributingAction.buildEnvVars"

This interface is not currently compatible with Pipeline I am afraid.

Anyway where steps should provide information to other steps in the
build, it is better to implement `Step` directly (rather than
`SimpleBuildStep`), and have a non-void return value.

[sohl]

Appreciate the quick reply.

Could you please elaborate on implementing 'Step'? SimpleBuildStep extends hudson.tasks.BuildStep. Do I need to implement BuildStep? What exactly should return the Non-null value.

Gleaning information from existing documentation is nearly hopeless, and randomly poking around core and plugins' code even with debugger takes forever.

[Jesse Glick]

On Fri, Feb 17, 2017 at 11:53 AM, sohl <mahr...@gmail.com> wrote:
> Could you please elaborate on implementing 'Step'?

https://github.com/jenkinsci/workflow-step-api-plugin/#writing-pipeline-steps

[sohl]

The page asks to

----------------------------

... Extend StepDescriptor. Pass the execution class to the super constructor. ...

-------------------

This is misleading.

"Super constructor" of org.jenkinsci.plugins.workflow.steps.StepDescriptor doesn't take any parameters. Sample implementations all use deprecated API (extends AbstractStepDescriptorImpl).

Are there are any samples of directly implementing "StepDescriptor" and how to handle the 'Execution' class?

[Jesse Glick]

On Wed, Feb 22, 2017 at 12:02 PM, sohl <mahr...@gmail.com> wrote:
> This is misleading.

Right, deleted.

> Sample implementations all use deprecated API
> (extends AbstractStepDescriptorImpl).

Sorry, which sample implementations?

> Are there are any samples of directly implementing "StepDescriptor" and how
> to handle the 'Execution' class?

Most of `workflow-basic-steps`, though in some cases
`AbstractStepExecutionImpl` is still used for reasons of compatibility
with builds started using earlier plugin versions.

[sohl]

Well, by samples I meant whatever existing implementations e.g.

https://github.com/jenkinsci/pipeline-utility-steps-plugin

public class ReadYamlStep extends AbstractStepImpl {}

public class ReadPropertiesStep extends AbstractStepImpl {}

...

I checked many plugins listed as pipeline compatible:

https://github.com/jenkinsci/pipeline-plugin/blob/master/COMPATIBILITY.md

and was not able to find a single one that wouldn't use the deprecated API.

Without knowing the Jenkins internal processing logic and facing outdated plugin implementations that's a pain to develop. Salt documentation looks like heavenly revelations now when comparing to Jenkins' docs.

The following sentence from https://github.com/jenkinsci/workflow-step-api-plugin/#writing-pipeline-steps

"You will also need to enumerate the types of contextual objects you are treating as required."

Enumerate how? What contextual objects? Treating as required by what...  reminds me:

"Who, or why, or which, or what, Is the Akond of SWAT?" - just kidding.

[Jesse Glick]

On Fri, Feb 24, 2017 at 10:21 AM, sohl <mahr...@gmail.com> wrote:
> and was not able to find a single one that wouldn't use the deprecated API.

As I said, check `workflow-basic-steps-plugin` which I have updated.
The new APIs are pretty recent so I would not expect adoption to be
widespread yet.

BTW: https://github.com/jenkinsci/workflow-step-api-plugin/pull/22