(Back from vacation.)
On Monday, July 15, 2024 at 4:52:04 PM UTC+2 jgl...@cloudbees.com wrote:
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.
That's a splendid suggestion. Much cleaner and easier to maintain. I don't
know when or if I'll be able to work on this but I've
filed https://github.com/jenkinsci/eiffel-broadcaster-plugin/issues/122 for
tracking purposes.
Thanks,
Magnus
--
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/0b3e8087-8a0d-4f7a-88fc-d091294302c9n%40googlegroups.com.
