Too many parameters pass to dependencies using reverse.dep.*.XXX

Completed

Hi,

We have a composite pipeline that pass 2 parameters to 2 different pipelines in de chain like:

reverse.dep.PIPELINE1.XXX

reverse.dep.PIPELINE2.YYY

This is working, and only XXX parameter arrive to PIPELINE1, and only YYY parameter to PIPELINE2

The problem is, if I add in the composite pipeline other like this:

reverse.dep.*.ZZZ

Then, both previous parameters (XXX and YYY) arrive to both pipelines, and we need to isolated YYY parameter to arrive ONLY to PIPELINE2, and the same with XXX parameter to PIPELINE1

4 comments
Comment actions Permalink

Hi Luis,

I've been trying to replicate this and have only partially done so. In my test, XXX and YYY arrive to one of the two build configurations but the second configuration gets only the one expected exclusive override and the shared one. This might be due to complexity of the scenario or setup, but there is definitely something wrong in there. I've created an issue in our tracker for it: https://youtrack.jetbrains.com/issue/TW-64115 . Please watch and vote for it.

 

Just for confirmation, having the overriding config (the one that sets the reverse.dep) be composite or not does not seem to have any impact.

0
Comment actions Permalink

Hi Denis,

It doesn't matter if the "main" build is composite or regular. To give you information more clarify, here is the chain that I'm using (with the parameters in the affected builds):

With this configuration, the execution of "F Deployment" works as I expected, and I can see these parameters in the execution chain in each build:


After, I've added new parameter in "F Deployment": reverse.dep.*.API_URL, and here is the result:

 


The thing here that I think is strange is: Why the parameter "env.APP_VERSION" arrives in "Post-Prepare"?

0
Comment actions Permalink

Hi Luis,

 

a couple comments. I know it does not matter, that's what I stated. While I appreciate all your extra effort to describe the issue, I'd like to direct you to the issue tracker entry I posted in my previous message. In particular, it was acknowledged as a bug from the development team, it has already been fixed in the code and verified, and it should be available in the release that we have published today.

 

So to answer fully, it happens because of a bug, it has been fixed at the time of this writing and it should be available in 2019.2.1 which has just been released.

0
Comment actions Permalink

Hi Denis,

 

It sound great. Thanks for you support and sorry for the delay in my last response. The dev team was faster than me clarifying the problem :D :D

 

Regards

0

Please sign in to leave a comment.