On Fri, Jul 12, 2024 at 4:51 PM Magnus Bäck <magnus.b...@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.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1YwcVseP-YkHe-8gYx2oZknd04AVRkgP%2Bwx3eWRNyOVg%40mail.gmail.com.
