APIs to expose build parameters to trigger builds

[ikedam]

Hello,

Let me know the best way to expose information to trigger builds from programs.

Extensible-choice-parameter plugin provides choice parameters whose choices are calculated dynamically, for example, with Groovy scripts.

I received a pull request to expose those choices with @Export annotation, which allows programs retrieve choices via REST API:

https://issues.jenkins-ci.org/browse/JENKINS-63786

https://github.com/jenkinsci/extensible-choice-parameter-plugin/pull/43

I'm not sure using @Export annotation is the best way as:

* REST API looks expected to use to expose configurations, that is, to expose static attributes rather than calculated results.

* REST API is accessible from users with Item/READ permissions. The current version of extensible-choice expose calculated values only to users with Item/BUILD or Item/CONFIGURE permissions.

What's the best way to expose choices?

Especially what I want to know are:

* Does Jenkins provide alternate interface to expose parameter information to trigger builds for programmatic consumption?

* Is there a way to add API for build parameter definitions  of jobs? I know that a model object exposed with URL path/to/model can provide a new URL path/to/model/foo by creating a new method `doFoo()`, but there look no URLs for parameter definitions of jobs. 

Regards, Ikedam.

[Jesse Glick]

On Sat, Oct 17, 2020 at 11:49 PM ikedam <iked...@gmail.com> wrote:
> REST API looks expected to use to expose configurations, that is, to expose static attributes rather than calculated results.

Not really. There is an export API from builds (`Run.getApi`), for
example, which is clearly dynamic.

> REST API is accessible from users with Item/READ permissions. The current version of extensible-choice expose calculated values only to users with Item/BUILD or Item/CONFIGURE permissions.

If there is some security reason to restrict information, simply guard
the `@Exported` getter with a `hasPermission` call, returning an empty
result for users without permission.

Note that this would affect other uses of the getter, which is usually
what you want: the caller is either internal, running as `ACL.SYSTEM`,
or is actually part of an authenticated request, in which case the
permission check is appropriate. If you really must retain the
original behavior, add a new getter with an arbitrary name which is
marked `@Restricted(DoNotUse.class) @Exported(name =
"originalPropertyName")` and does the permission check.

[ikedam]

Adding a new getter sounds good and easy.

I'll try that.

Thank you!

2020年10月19日月曜日 23:41:08 UTC+9 Jesse Glick: