|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[~Jesse Glick] that seems like good advice, but there are a number of use cases where external libraries provide enormous value and don't involve significant I/O or computation.
For me, the most important are web service client libraries, which would be terrific to be able to conveniently use from a workflow script to coordinate all the busy work that surrounds building and deployment.
After a brief fit of frustration trying to add support for @Grab to the cps/workflow-cps-plugin, I ended up writing/re-writing a half-dozen REST client libraries in Groovy scripts so that our build and deployment process could coordinate with JIRA, HipChat, GitHub, and release notes website. Using only 'sh' step, I also finally have great 'library' for managing deploys to AppEngine!
The result is actually quite nice, but now I have, for example, the source for a GitHub client code locked into a git repo on our jenkins server – and no clear way to contribute this back to other users.
If not Grape, we need some way to package and reuse workflow logic, and the jenkins plugin mechanism feels too heavy after getting used to a rapid change, push, and build 'workflow'.
Do you guys have a general direction in mind for this kind of code reuse?