APIs to expose build parameters to trigger builds

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

APIs to expose build parameters to trigger builds

ikedam-2
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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8930b78e-3cb4-4a70-82d3-26d218bee4adn%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: APIs to expose build parameters to trigger builds

Jesse Glick-4
On Sat, Oct 17, 2020 at 11:49 PM ikedam <[hidden email]> 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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1J_NKoZbkQdOnQ9Qfknc7-3fR%3DAKWLHUadiGV3%3DHzuLg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: APIs to expose build parameters to trigger builds

ikedam-2
Adding a new getter sounds good and easy.
I'll try that.

Thank you!


2020年10月19日月曜日 23:41:08 UTC+9 Jesse Glick:
On Sat, Oct 17, 2020 at 11:49 PM ikedam <[hidden email]> 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.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/894bdd21-104b-41a5-a78f-545a7b2e057en%40googlegroups.com.