Is it possible to include parameters in reverse dependency parameter Follow
Answered
Our build system includes builds for different mobile platforms (4 different configurations), and another build configuration (composite) that triggers these other 4 configurations.
When we'd like to create a new release, we trigger the composite build which builds all required builds.
The composite build "injects" parameters into its dependencies via the "reverse dependency" notation:
My question is - is it possible to include other parameter values as the value for this? a quick test shows that it's not possible (e.g: if i put %global.version% it will be passed as is, and not as the resolved value).
Is there any way to achieve what i want ?
Please sign in to leave a comment.
I'm not sure I completely understand your question. You are correct that the reverse.dep parameters will be passed to the dependencies and you appear to be using this correctly, but can you please elaborate as to how %global.version% is being used in your case? How is %global.version% being defined in your build chain? Feel free to include screenshots of how or where you are using it.
Thanks for your reply! %global.verson% was only an example.
The point is that dependent builds have a parameter named build.bundleVersion, when i tried to use the reverse dependencies notation with some value that included other parameters in it, the value was passed "as-is" and not as the actual resolved value.
For example, if my top-most project has some parameter named global.version with a value of 1.5.0, if i would run the above example like this:
reverse.dep.*.build.bundleVersion with a value of %global.version% then the dependent builds would get "%global.version%" (as a string) in their build.bundleVersion, and not the actual resolved value.
I hope this exaplantion makes it clearer as to what i meant originally.
Thanks for the clarification. So if you set reverse.dep.*.build.bundleVersion = %global.version%, the %global.version% will be pushed to the dependency build "as-is" and will actually be resolved in the dependent build. Here is an excerpt from our documentation on the subject:
"Note that the values of the
reverse.dep.parameters are pushed to the dependency builds "as is", without reference resolution. %-references, if any, will be resolved in the context of the build where the parameters are pushed to.<property name>is the name of the property to set in the noted build configuration. To set system property,<property name>should contain thesystem.prefix."We do have a request in our YouTrack that seems to be related to your question, https://youtrack.jetbrains.com/issue/TW-42994. I've added your post here as an internal note on that request. Feel free to vote and leave any comments, including your use case, on the YouTrack site. We use our public YouTrack site to determine which features are added in future releases.
I am not sure i understand that piece of documentation. what does it mean:
%-references, if any, will be resolved in the context of the build where the parameters are pushed to.
<property name>is the name of the property to set in the noted build configuration.Let's say you have two build configurations, A and B. Build B has a snapshot dependency on Build A.
In Build B, you have added the following parameter: reverse.dep.*.example = %build.number%
When you run Build B, it passes this parameter to Build A explicitly as follows: example = %build.number%
Build A will resolve %build.number% as the current build number for Build A. The parameter "example" becomes equal to the current Build A build number.