Your browser was unable to load all of the resources. They may
have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.
Hello,
A feature that would be nice for us to have:
1) A new field on all step types that takes a list of key/value variable pairs.
2) Before the step runs, those pairs are added to build.variables.
3) After the step runs, the value (or non-existence) of each key from before the step ran is restored.
4) The parameters on a step are are stored in the parent (Composition) step rather than the child step, so that adding parameters to a step does not create a local override of the step.
We could workaround 1,2,3 by adding code to do this ourselves in the Pre Execute Action and Post Execute Action fields that already exist on all step types, but there's no way we've thought of to handle #4.
The context in which we want this:
We have some shared Groovy script Steps that we define in our root configuration: Copy Build, P4 Integrate, etc
We call these Steps from any arbitrary configuration, and we need to specify source and target or other parameters for the Steps to run.
We are continuing to improve and optimize these shared Steps, so we don't want to make an override that would prevent us from getting the changes we're making to the Groovy in the child configurations where the Steps are used.
In the absence of a parameter field that does not override the Step, we've been setting up the parameters in a separate Step that we call before the shared Step runs, but the downside of that is that it makes the Configuration harder to read due to the presence of the extra Steps.
Is it possible to add such a feature to quickbuild, or do you have any recommendations for a better way to create and use shared steps?
Thanks,
Matt
-
replies
4
-
views
4405
-
stars
0
-
I'd suggest to utilize the repeat parameter concept to customize behavior of shared step. The repeat parameter concept is originally created to repeatedly calling a step with different parameters, but it can also be used here to customize the behavior of shared step, just that you only need to run it once. For instance, you may contain below logic in your shared groovy script:
groovy:
if (params.get("platform") == "windows" && params.get("db") == "mysql") {
// do something
} else {
// do some other thing
}
And then you can put the shared step into a sequential container, and edit advanced setting of the sequential container to define repeat parameter required by the groovy script for instance:
name: platform, values: windows
name: db, values: mysql
Here each param has only one value, so the step will only be run once.
Hi Robin,
That works, and handles the removal of the variables from the global namespace. We'll change our best practice for shared steps to use that method.
It's not quite a perfect solution since it requires editing the params on a parent step.
If we keep a single parent Step with the params for multiple shared Steps on it, and we have a parent Step with ~10 child Steps, 2 of which are shared Steps, it becomes a bit harder to read/maintain, since we have to view/edit the params for the 2 shared Steps on the parent Step that is half a screen above.
Alternatively we can wrap each shared Step in its own parent Step, and then edit the parameters just for that step on the small parent Step, but then that adds in an extra Step that shows up in the UI and makes the Configuration a little harder to read.
But it's better than what we were doing and seems like only a minor inconvenience, so I think fixing those are low priority even as a nice to have.
Thanks,
mrp
Hi Robin,
After further discussions we came to the conclusion that while using the repeat parameters can work, there are still sufficient drawbacks that we would like another solution if you can think of one.
1. To make use of the repeat parameters we think the best way is to wrap the parameterized step in an additional composite step. Even doing it this way, however, is cumbersome, and with multiple parametric steps it clutters up the interface pretty quick.
2. If we by accident (or by requirement) include a comma in the parameter value, then that will be treated as a repeat parameter list and a set of parameter permutations will be generated and the step will be executed multiple times. This is inconvenient at best, and can lead to unforeseen breakages if the parameter value comes from an external source (such as parsed by a script and stored in a variable beforehand for example).
The following would be the ideal solution for us:
• Define a new step. (For example: name = "Copy Directory", type = "Shell Command", value = "robocopy ${args.get('source')} ${args.get('target')}")
• Define a set of parameters for that step. (For example: 'source' and 'target', possibly with default values)
• Drag the step into a configuration, set the parameters. (For example: source = "Bin/release", target = "Storage/${vars.getValue('BuildId')}")
• Drag the step into the configuration again, set different parameters. (For example: source = "Shared/Tools/Generator", target = "Bin/Tools/Generator")
• The different parameters shouldn't count as an override. If I define this "Copy Directory" step at the root level with a given behavior, with a given set of parameters, then use it in multiple configurations with different parameters – then I should be free to change the behavior at the root level (for example: always retry the copy 5 times) and all parametric instances should be affected (as long as I have only modified their parameters and not their behavior).
Ideally we should be able to reuse the step even within the same scope (something which doesn't quite work right now, as the same step can only be present once within the same scope).
Regards:
Andras
Hi Andras,
We'd rather not to add a separate parameter mechanism for steps as there will be too many concepts to handle, considering there are already repetition parameter concept there. We can enhance the current repetition parameter to give it an option to ignore comma so that it does not produce multiple values unintentionally. I filed an improvement request for this as:
http://track.pmease.com/browse/QB-2743
