Extending descriptors

[zbyne...@gmail.com]

Should it be possible for a step descriptor to extend a descriptor of another step, as implemented in https://github.com/jenkinsci/eiffel-broadcaster-plugin/blob/350096b9e91efe5a16ce52489c1e5bdf3d6cea14/src/main/java/com/axis/jenkins/plugins/eiffel/eiffelbroadcaster/pipeline/build/BuildWithEiffelStep.java#L52 ?

This currently confuses the pipeline step documentation (see https://github.com/jenkins-infra/jenkins.io/issues/7400 for more context), I'm trying to figure out if that's a plugin issue or docs issue.

Thanks,
Zbynek

[Jesse Glick]

On Thu, Jul 11, 2024 at 2:30 PM zbyne...@gmail.com <zbyne...@gmail.com> wrote:

Should it be possible for a step descriptor to extend a descriptor of another step

Possible but not a normal practice. You can create a separately rooted `StepDescriptor` that delegates selected web methods.

From reading the Javadoc, I would advise not taking this approach of a custom step. Maybe you want to listen to uses of the stock `build` step and attach some extra information automatically? Or pass a build parameter which would trigger some special behavior? Etc.

[Magnus Bäck]

On Thursday, July 11, 2024 at 9:18:25 PM UTC+2 jgl...@cloudbees.com wrote:

From reading the Javadoc, I would advise not taking this approach of a custom step. Maybe you want to listen to uses of the stock `build` step and attach some extra information automatically? Or pass a build parameter which would trigger some special behavior? Etc.

The goal of the `buildWithEiffel` step is to provide a pipeline step for starting builds with an additional string option that's attached to the Run via an action (so that a QueueListener can pick up the string later on). Passively listening to the stock `build` step won't allow the user to supply the string in the first place. Using a build parameter (possibly of a custom type) to pass the string would technically work, but using parameters as a general key/value store for passing values that aren't meant to reach the actual build seems like a bit of a hack.

I'd love for the `build` step to support an extension point whose implementations can receive additional step arguments.

Thanks,

Magnus (maintainer of the offending eiffel-broadcaster plugin)

[Jesse Glick]

On Fri, Jul 12, 2024 at 4:51 PM Magnus Bäck <magnu...@axis.com> wrote:

I'd love for the `build` step to support an extension point whose implementations can receive additional step arguments.

If the `build` step in fact does what you want other than this, it would not be difficult to define a `Describable` extension point for an argument which contributes `Action`s to the `Queue.Item`, e.g.

build job: 'downstream', options: [eiffel(something: 123)]

where your plugin would define something like

public final class EiffelBuildStepOption extends BuildStepOption {

  @DataBoundConstructor EiffelBuildStepOption(int something) {…}

  @Override List<Action> produceActions(Job<?, ?> downstreamJob, …) {…}

  @Symbol("eiffel") @Extension public static final DescriptorImpl extends BuildStepOptionDescriptor {}

}

If you want to experiment with an API like that, my advice is to file the upstream PR to `pipeline-build-step-plugin` defining the API with a synopsis of the motivation, and concurrently file a draft downstream PR to your own plugin consuming the upstream PR via an incremental version dep and verifying that the system works in a `JenkinsRule` test running an example upstream/downstream build pair.