Refactor providers to be Describable #51
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
src/main/java/io/jenkins/plugins/explain_error/provider/BaseAIProvider.java
Fixed
Show fixed
Hide fixed
src/main/java/io/jenkins/plugins/explain_error/provider/OllamaProvider.java
Fixed
Show fixed
Hide fixed
src/main/java/io/jenkins/plugins/explain_error/provider/OpenAIProvider.java
Fixed
Show fixed
Hide fixed
src/main/java/io/jenkins/plugins/explain_error/provider/OpenAIProvider.java
Fixed
Show fixed
Hide fixed
The current implementation based on an enum is not very flexible, It basically avoids that one can write an implementation of another provider in a separate plugin. And one has to change a lot of places to create a new provider. This change makes the provider an ExtensionPoint. This has some advantages like provider specific requirements checking. E.g. the apiKey is mandatory for OPOenAI and Gemini but not required for Ollama. And for Ollama a url is mandatory. The code is also a lot simpler and avoids special checks. Providers implement checks if the config is valid avoiding unnecessary calls to the provider when we know the request will fail anyway, e.g. due to a missing apikey or a missing model. This would also make it easily possible to change the plugin to have multiple providers configured, either from different providers or different modeld from the same provider.
mawinter69
force-pushed
the
provider-rewrite
branch
from
19e2c07 to
b8ea815
Compare
|
|
||
| </dependencies> | ||
|
|
||
| <build> |
There was a problem hiding this comment.
No need to disable the enforcer rules with configuring corresponding exclusions
include the provider name when displaying existing explanations add a tooltip to the Explain error button in the appbar of the console view
shenxianpeng
added
the
major-rfe
|
Thank you so much for these awesome changes! Can’t wait to see users benefit from them soon. |
| } | ||
|
|
||
| @Test | ||
| void testExistingExplanationDetection() { |
There was a problem hiding this comment.
All the removed tests didn't test anything from the ConsoleExplainErrorAction class. What they tested is already covered in ErrorExplanationActionTest
|
For sidebar name — it would be even better if it didn’t change based on the provider name. 
After entering the API key for OpenAI, the “Field is required” message still appears. (It works fine for Gemini.) 
|
Fixed that.
I'm not able to reproduce that. Note that the check is only executed after the field loses focus |
|
@MarkEWaite I Will test over the weekend |
|
I’ve tested the latest changes and everything looks good. If there are no further updates or comments, I plan to merge this on Monday or Tuesday next week. Thanks a lot! |
closes #55 fixup of #51 ### Testing done <!-- Comment: Provide a clear description of how this change was tested. At minimum this should include proof that a computer has executed the changed lines. Ideally this should include an automated test or an explanation as to why this change has no tests. Note that automated test coverage is less than complete, so a successful PR build does not necessarily imply that a computer has executed the changed lines. If automated test coverage does not exist for the lines you are changing, you must describe the scenario(s) in which you manually tested the change. For frontend changes, include screenshots of the relevant page(s) before and after the change. For refactoring and code cleanup changes, exercise the code before and after the change and verify the behavior remains the same. --> ### Submitter checklist - [x] Make sure you are opening from a **topic/feature/bugfix branch** (right side) and not your main branch! - [x] Ensure that the pull request title represents the desired changelog entry - [x] Please describe what you did - [x] Link to relevant issues in GitHub or Jira - [ ] Link to relevant pull requests, esp. upstream and downstream changes - [ ] Ensure you have provided tests that demonstrate the feature works or the issue is fixed <!-- Put an `x` into the [ ] to show you have filled the information. The template comes from https://github.com/jenkinsci/.github/blob/master/.github/pull_request_template.md You can override it by creating .github/pull_request_template.md in your own repository -->
3 participants
The current implementation based on an enum is not very flexible, It basically avoids that one can write an implementation of another provider in a separate plugin. And one has to change a lot of places to create a new provider.
This change makes the provider an ExtensionPoint. This has some advantages like provider specific requirements checking. E.g. the apiKey is mandatory for OpenAI and Gemini but not required for Ollama. And for Ollama a url is mandatory.
The code is also a lot simpler and avoids special checks. Providers implement checks if the config is valid avoiding unnecessary calls to the provider when we know the request will fail anyway, e.g. due to a missing apikey or a missing model.
This would also make it easily possible to change the plugin to have multiple providers configured, either from different providers or different models from the same provider.
Existing configuration is automatically converted to the new format.
When disabling the plugin the configuration of the provider is not lost.
Also fixes #31
Open points:
Before:
After:
No dropdown when disabled:
Dropdown with specific config when enabled
Ollama:
OpenAI:
Testing done
Adjusted the tests accordingly.
Added tests that ensure the old config formats for the xml and casc are loaded properly
Submitter checklist