[JENKINS-72695] Gerrit Trigger Plugin: Use of RestAPI /plugins to determine if a plugin is present

[jenkins-infra-bot]

In the plugin code (GerritPluginChecker.isPluginEnabled) the validator determines if a plugin exists and is active through an HTTP call to the root endpoint of the plugin and examining the response code.

Example for the events-log: 

curl -o - -I http://localhost:8080/plugins/events-log/

HTTP/1.1 302 Found

Date: Thu, 08 Feb 2024 12:11:34 GMT

X-Frame-Options: DENY

Location: http://localhost:8080/plugins/events-log/Documentation/index.html

Content-Length: 0

 

This page is then redirected by Gerrit to the documentation page of the respective plugin. Gerrit requires the transformation of the documentation page for presentation purposes (markup), which is an expensive task to perform.

 

While this works in theory, on large enterprises with multiple Jenkins servers this corresponds to many redundant calls to Gerrit (have seen above 300 calls/second), which is not ideal.

 

The usual workaround in multiple Gerrit setups is forcing the caching of this information (events-log), but that does not address the real issue, which is the usage of a help page to determine if a plugin is active.

 

Gerrit provides a specific Rest API for plugin queries, which is:

 

https://gerrit-review.googlesource.com/Documentation/rest-api-plugins.html#list-plugins

 

Example of an active plugin:  curl -u user:password  http://localhost:8080/a/plugins/?r=events-log

)]}'

{"events-log":{"id":"events-log","version":"a831e7948b","api_version":"3.9.0-SNAPSHOT","index_url":"plugins/events-log/","filename":"events-log.jar"}}

 

Example of an inactive/non-existent plugin: curl -u user:password   http://localhost:8080/a/plugins/?r=events-log

)]}'

{}

 

I suggest the usage of this one instead of what is currently being done.

---

Originally reported by josegranha, imported from: Gerrit Trigger Plugin: Use of RestAPI /plugins to determine if a plugin is present

• assignee: rsandell
• status: Open
• priority: Minor
• component(s): gerrit-trigger-plugin
• resolution: Unresolved
• votes: 0
• watchers: 1
• imported: 2025-12-07

Raw content of original issue

In the plugin code (GerritPluginChecker.isPluginEnabled) the validator determines if a plugin exists and is active through an HTTP call to the root endpoint of the plugin and examining the response code.

Example for the events-log: 

curl -o - -I http://localhost:8080/plugins/events-log/

HTTP/1.1 302 Found

Date: Thu, 08 Feb 2024 12:11:34 GMT

X-Frame-Options: DENY

Location: http://localhost:8080/plugins/events-log/Documentation/index.html

Content-Length: 0

 

This page is then redirected by Gerrit to the documentation page of the respective plugin. Gerrit requires the transformation of the documentation page for presentation purposes (markup), which is an expensive task to perform. 

 

While this works in theory, on large enterprises with multiple Jenkins servers this corresponds to many redundant calls to Gerrit (have seen above 300 calls/second), which is not ideal.

 

 The usual workaround in multiple Gerrit setups is forcing the caching of this information (events-log), but that does not address the real issue, which is the usage of a help page to determine if a plugin is active.

 

Gerrit provides a specific Rest API for plugin queries, which is:

 

https://gerrit-review.googlesource.com/Documentation/rest-api-plugins.html#list-plugins

 

Example of an active plugin:  curl -u user:password  http://localhost:8080/a/plugins/?r=events-log

)]}'

{"events-log":{"id":"events-log","version":"a831e7948b","api_version":"3.9.0-SNAPSHOT","index_url":"plugins/events-log/","filename":"events-log.jar"}}

 

Example of an inactive/non-existent plugin: curl -u user:password   http://localhost:8080/a/plugins/?r=events-log

)]}'

{}

 

I suggest the usage of this one instead of what is currently being done.