为了表示我的诚意, 这是我自己写的宣言式Jenkinsfile适配github的withCredentials
https://github.com/showerlee/gradle-demo-with-docker-multibranch/blob/master/Jenkinsfile#L46

本身Jenkinsfile里面不需要有任何webhook的配置就直接能够集成github.

如果觉得我的issue提的没有意义, 那就直接close吧.
毕竟是免费插件, 我还是非常尊重你们的劳动成果
但这个gitee我觉得对我个人而言的确没有什么使用价值

triggers无法通过我们的修改来支持withCredentials，我只能给您另外的参考解决方案，所以我关闭了这个issue，关于如何更安全的使用这个token，您可以在原issue继续留言，我仍会尽我所能提供最大帮助，无论这个issue是否关闭。

至于解决的方案，如果不想在脚本中暴露明文密码，可以使用环境变量方案，在jenkins中添加全局环境变量

脚本中创建触发器时填写secretToken时引用变量：secretToken: "${env.GITEE_TOKEN}"
这样就可以避免在Jenkinsfile中使用明文密码，至于需不需要用到凭证管理，我觉得没有必要，因为这个secretToken在配置中最终是明文显示的：

感谢@silverballer的解答.
这个通过引入环境变量的解决方案虽然能够避免在源脚本中明文暴露token, 但是并无法解决密码会显示的暴露在Jenkins build日志里.

而使用withCredentials除了方便管理和调用, 另外一个好处就是他本身就会通过***在日志里屏蔽敏感信息.
这是我的使用它屏蔽TOKEN的截图

而且在生产上使用这个方法, 仍然存在如下几个问题:
1.无法对ci的秘钥进行集中管理, 需要第三方加密工具引入
2.无法完全CI/CD代码化(也就是俗称的pipeline as code)
3.无法屏蔽日志敏感信息.
4.变量明文配置在CI后台, 存在安全隐患.

其实我觉得如果贵插件能够兼容withCredentials使用那将是非常好的.
否则还是建议参考github插件, 将这层hook配置与Jenkins的blueocean集成 或者能够将这个配置剥离出pipeline的配置当中.
这样子也能够实现github与很多CI视图进度集成的功能.

这些功能实现了, 我觉得gitee在国内的受众会多很多.
当然这只是我的个人理解, 仅供参考.

现在我使用的方法是，gitee事件触发jenkins job A，job A直接传递参数调用其他的jenkinsfile的build job B和test job C。这样是不是避过了一些你们提到的一些credential的对接问题？