[JENKINS-26135] Allow CPS global lib scripts to define global variables #131
Conversation
This allows the release engineering team to define higher-level
organization specific workflow DSLs.
This is critical to use workflow as "simplified text-based UX".
Such DSLs could be for example:
acmeCorp {
id = '123'
devEnvironment = 'qa-svr-1'
}
(where let's say there's an inventory of application ID in the
central database describing where the repository is, and 'qa-svr-1'
refers to the Tomcat server where the app gets deployed at the end.)
|
I could have avoided registering/unregistering a new It looks like |
|
|
Well, it is in 1.7-alpha-1, but I think it is fine to change its signature if that makes this easier. |
| * @author Kohsuke Kawaguchi | ||
| */ | ||
| // not @Extension because these are manually registered | ||
| public class UserDefinedGlobalVariable extends GlobalVariable { |
|
As with @oleg-nenashev I am a little concerned about overloading |
|
BTW you should add a |
| @@ -0,0 +1,4 @@ | |||
| <?jelly escape-by-default='true'?> | |||
| <j:jelly xmlns:j="jelly:core"> | |||
| <j:out value="${it.helpHtml}"/> | |||
There was a problem hiding this comment.
Careful—this is user content emitted raw. It would be safer to use MarkupFormatter, or restrict to plain text. Admittedly it currently requires RUN_SCRIPTS to push to this repo, but see JENKINS-26538.
There was a problem hiding this comment.
All right, I'll do MarkupFormatter and probably name those files as just *.txt.
I guess this use case, if it ever comes up, could be treated as an additional feature—so long as we use distinctive subdirectory names. Other than the comments above this looks good to me. BTW have you checked that this functionality is not already possible without any change? Since |
|
As an aside, the consistent feedback I hear from everyone I talk to about Workflow scripts is that they want to keep all sources in their own Git repositories (or other SCM), and thus would not use this plugin. Not blocking this PR but we should be considering how similar features could be built using external SCMs. |
|
Yet these behave in subtly different ways. One creates a class definition, one a variable. Just worried that this is adding yet another mine to the field; see the explanation of explicit vs. implicit classes in Do not feel strongly about it, but I still find it clearer to use a separate directory namespace for a distinct feature.
Not sure I followed that. Anyway this PR should do something to clean up the interaction with |
People using another Git repository as the source of truth is anticipated and well supported. They just need to "deploy" the changes by pushing it into this repo, which is the same thing Heroku and others do. Using other SCMs would indeed go beyond the capability of this repository. Maybe we can split |
Better to do nothing until we implement that future expansion and see exactly what it requires. I suspect that it should work like, or even as a part of, |
|
Are you still working on this? |
|
For the past two days I've been away. My understanding based on the conversation here is that the following tasks remain:
|
Your judgment call; I am only -0 on the current placement. |
|
BTW I took the liberty of moving your list into a GH tasklist for easier tracking. |
|
Just remembered JENKINS-26135, which requests automatically loaded global functions (opposed to variables) here. Seems like it would not be hard to generalize this a bit to allow you to hook into |
kohsuke
changed the title
|
Good point about JENKINS-26135. I think I should be able to solve it at the same time. |
… changing list of GlobalVariables. To make the common case easy, GlobalVariable is still left as a separate extension point. To reduce the error prone-ness of listing all variables, I added GlobalVariable.ALL.
... to prevent XSS vulnerability from attackers who can define scripts. MarkupFormatterDescriptor should declare the desired extension, so that if Jenkins is configured for a specific MarkupFormatter, such as MarkDown, then we can support it. Until that day, better to stick to plain text.
Global variable should be usable as a function, just like in Groovy Closure property can be called like a function.
…n the use case, not a syntactic variant.
|
🐝 |
| z.checkOutFrom(repo) | ||
| ``` | ||
|
|
||
| ### Defining global functions |
There was a problem hiding this comment.
One of the use cases of this seem to be a friendlier syntax for workflow-compatible but not explicitly workflow-supporting plugins that would use generic steps. Maybe have a specific example of that here?
There was a problem hiding this comment.
Hmm, for me the syntax simplification for the generic step is a problem on its own. You are right that this could be a workaround while we solve that, but not sure if we want to advertise it in README.
There was a problem hiding this comment.
Right that is a separate (filed) issue, not really related to this PR.
|
What happens when a file name such as |
|
🐛 until the |
|
|
|
@kohsuke you closed the repository for |
@kohsuke It looks like it would show up in the list though when it should not. |
|
|
||
| The `vars` directory hosts scripts that define global variables accessible from | ||
| workflow scripts. | ||
| The basename of each `*.groovy` file should be a Groovy (~ Java) identifier, conventionally `camelCased`. |
There was a problem hiding this comment.
must, if you want it to work.
It would, but oh well. Just do not do that. |
|
Right. Good enough I suppose. 🐝 |
| The `vars` directory hosts scripts that define global variables accessible from | ||
| workflow scripts. | ||
| The basename of each `*.groovy` file should be a Groovy (~ Java) identifier, conventionally `camelCased`. | ||
| The matching `*.txt`, if present, can contain documentation, processed through the system’s configured markup formatter |
There was a problem hiding this comment.
This seems bad - as this can be changed independently and then this would affect the help rendering here.
I guess no different to all the job descriptions though.
There was a problem hiding this comment.
Yes, the same problem applies to any saved markup I am afraid.
The forced *.txt extension is ugly but MarkupFormatterDescriptor lacks an API for specifying a conventional file extension.
|
🐝 couldn't see anything obviously wrong. |
| File help = source(".txt"); | ||
| if (!help.exists()) return null; | ||
|
|
||
| return Jenkins.getActiveInstance().getMarkupFormatter().translate(FileUtils.readFileToString(help, Charsets.UTF_8)); |
There was a problem hiding this comment.
I assume there's a default Markup Formatter ?
|
🐝 Insofar as I get it. Only potential problem I saw was the potential NPE in |
[JENKINS-26135] Allow CPS global lib scripts to define global variables
This allows the release engineering team to define higher-level organization specific workflow DSLs.
This is critical to use workflow as "simplified text-based UX". Such DSLs could be for example:
(where let's say there's an inventory of application ID in the central database describing where the repository is, and 'qa-svr-1' refers to the Tomcat server where the app gets deployed at the end.)
varsdir and pick scripts from there, not fromsrc. (perhaps)GlobalVariableAPI to get rid of dynamic extension list manipulation.LoadStepTest.basicsfailure@reviewbybees