Closed agabrys closed 1 year ago
@oleg-nenashev could you take a look? A very small PR which makes the tools management safer.
Jenkins failure is not related to the introduced changes. I have no powers to restart the build, so I force pushed the commit so scheduled it again.
If you prefer, I can change it from custom
to customTool
. However, it looks a little redundant to me:
tool name: 'xyz', type: 'custom'
vs.
tool name: 'xyz', type: 'customTool'
Where other don't use the suffix:
tool name: '17', type: 'jdk'
tool name: '3.2.5', type: 'maven'
tool name: '16', type: 'nodejs'
Please decide. I'll update (or not) based on the decision the PR and then we may merge it and maybe even release a new version (would be great) 🙂
Ping 🙂
Pong 🎾
If there is no issue, can someone accept the PR ? If I understand properly this conversation, this is the single thing that prevents to use Custom Tools in a declarative pipeline.
@oleg-nenashev Is there any reason that this PR is not merged yet?
Hello, there are 2.key reasons:
All contributors interested in the plugin are welcome to step up as maintainers. Thanks for understanding
This plugin is up for adoption, I no longer actively maintain it
I would consider adding a notice in README.md
telling that this repository is not actively and give a hyperlink to https://www.jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/.
I am on sabbatical in the Jenkins community because of the war in Ukraine and the personal situation
I wish you all the best ❤️
The
@Symbol
annotation defines a unique identifier which is used by DSL. Whit this commit it is possible to distinguish a difference between tools when the thetool
step is called. Example:Addresses JENKINS-37389 Add @Symbol("custom") to Custom Tool's ToolDescriptor.
I didn't add any tests. Every extension should be annotated with
@Symbol
. Its value must be unique within a specific extension point, and there are no other tools withcustom
identifier (the change is safe).