QB5.1.35: Repeat parameters changed to make unique? #3299

scastria · 10 years ago

I currently have a working build for my iOS project. I provide two variables to the build command called solutionConfig and solutionPlatform. I specify solutionConfig variable to be "Release" and solutionPlatform variable to be "iOS". Everything works and it builds the executable for the iOS device just fine.

However, I now have the need to run a build for both the device and the simulator. The combination for the device is Release/iOS as described above. The combination I use for the simulator build is Debug/iOS. Therefore, I decided to switch over to repeat parameters to get two builds with each combination of inputs. So I:

1. Changed variable name from solutionConfig to solutionConfigs
2. Changed variable name from solutionPlatform to solutionPlatforms
3. Changed value of solutionConfigs to "Release,Debug"
4. Changed value of solutionPlatforms to "iOS,iOS"
5. Changed build step command to use params.get() instead of vars.getValue()

I ran the build and got something unexpected. The first build step that was run with the first combination of build repeat parameters was:

Release and iOS#2

It appears that when the same value was found in the comma delimited list of repeat parameters, you automatically added a "#2" to make it unique? I would prefer you honor the values I specified in the comma delimited list. Is that possible to fix?

replies 4
views 2495
stars 0

scastria · 10 years ago

After trying some more things, I noticed that the build step is repeated with each combination of build parameters. That is what the help documentation says, but I could interpret that documentation 2 ways:

1. Interpretation 1:

Param1=1,2
Param2=A,B

build for each combination:
1,A
1,B
2,A
2,B

2. Interpretation 2:

Param1=1,2
Param2=A,B

build for each combination:

1,A
2,B

QuickBuild is using interpretation 1 and I believe it is better to use interpretation 2. If QB uses interpretation 1 (as it does today), there is NO easy way to get the results of interpretation 2. However, if QB uses interpretation 2, I can still implement interpretation 1 as a user if I want to by doing:

Param1=1,1,2,2
Param2=A,B,A,B

therefore, interpretation 2 gives the user more control and flexibility.

I hope this is making sense.

robinshen ADMIN · 10 years ago

QB uses interpretation 1 as it is simper for most scenarios, for instance, when you are adding another dimension, or add extra values of existing dimensions. Interpretation 2 will make the maintenance harder. For the situation you've encountered, QB needs to make sure each combination of parameters is unique as they are used as key to step instances. I'd suggest to only define a single parameter here, say "buildConfig", with vaue set to "iOS-Release, iOS-Debug" and then parse the param value to pass os and config to your build command as below:

/path/to/build/command --os ${com.pmease.quickbuild.util.StringUtils.substringBefore(params.get("buildConfig"), "-")} --buildType ${com.pmease.quickbuild.util.StringUtils.substringAfter(params.get("buildConfig"), "-")}

scastria · 10 years ago

I am curious: What scenario is Interpretation 1 useful? I am trying to think of when I would want all different combinations of 2 or more build parameters in my builds.

robinshen ADMIN · 10 years ago

This will be useful if you want to cross build/test a number of independent parameters, for instance for different combinations of OS types and release/debug configuration and database etc.