Does "Finish build trigger" with 'Trigger after successful build only' and snapshot dependency set get triggered on svn tags/ ?

Does "Finish build trigger" with 'Trigger after successful build only' and snapshot dependency set get triggered on svn tags/ ?

There seems to be a limitation when "Finish Build Trigger" is set to trigger on <svn-root>/tags/tag_name . Does anybody have seen such limiation before & if yes is there a workaround for this?

8 comments
Comment actions Permalink

Can you please provide more information?

Finish build trigger is used, when referenced build finishes regardless of what sources it was built against.

0
Comment actions Permalink

Our need is to trigger build B once build A is completed Successfuly. For which have tried setting finish-build-trigger in build B which depends on successful completion of A.

Another requirement is to get the artifact from build A in build B. To achieve this have set snapshot & arifact dependency on build A in build B . Finish build trigger is set in build B so as to get triggered automatically.

I looked at referenced documentation from TC :

 

a.    http://confluence.jetbrains.com/display/TCD7/Dependent+Build#DependentBuild-ArtifactDependency

 

Please note that if both snapshot dependency and artifact dependency are configured for the same build configuration, in order to take artifacts from the build with the same sources Build from the same chain option must be selected in artifact dependency.

 

 

b.  http://confluence.jetbrains.com/display/TCD7/Configuring+Build+Triggers  

 

Finish Build trigger
: the build is triggered after a build of the selected configuration is finished. If corresponding checkbox is enabled, a build is triggered only after successful build of the selected configuration.

Note that if build configuration with "Finish build trigger" has snapshot dependencies to selected build configuration, the trigger will run build on the same revisions and will attach build to the chain. Thus you can have automated promotion of builds in chain.


 

 


And to add, this setup works perfectly fine on trunk. On dynamically set tag-name it fails. Also another option tried to achieve it is here : http://devnet.jetbrains.com/thread/453998

 

0
Comment actions Permalink

Your setup looks correct.

Can you explain what means "dynamically set tag-name"? Does that mean that SVN url is set to http://mySvn/someProject/tags/%inpassed.tag.name%, whereas it works well for http://mySvn/someProject/trunk?

0
Comment actions Permalink

Yes, current setup looks that way. Tag name is set dynamically when build 'A' is run - by forcing it - which promts for entering tag-name to run the check-out & same value is used in build step as well.

So VCS root is framed in 'SVN Connection Settings' in URL with <svn.proj.root>/tags/%env.TAG_NAME_PASSED%

0
Comment actions Permalink

Dynamically (during build chain execution) customization of URL of VCS that participate in snapshot deps is not correct and TC doesn't support this. The thing is that URL and checkout rules of VCS are resolved at the time build chain is started and you can't change these parameters.

0
Comment actions Permalink

As you are correctly trying to do in parallel thread, the right thing is to start the build with a parameter representing tag name. I would also recommend you to have a single vcs root for both trunk and tag build, but use different checkout rules, i.e. trunk=>. and tags/%myTag%=>.

0
Comment actions Permalink

Both builds 'A' & 'B' are running on tags only and I have 'choosed VCS root to attach ' to be same one under 'Version Control Settings'. And it make sense of creating 'build chain' & resolvement of VCS root when main build is kicked-off.


P.S : Just to add in case of trunk it works as it is static value set in build A & B . If I change to dunamic tag which needs to be set when it is triggered it fails to do so. .. As you mentioned I am trying more on option of running custom script with 'curl' of triggering build B.

0
Comment actions Permalink

Just to make this more clear: before first build in chain starts (when chain is triggered), teamcity goes over all VCS roots in all builds that participate in chain, resolve all parameters (including URLs and checkout rules), records revisions for all VCS roots and only after that first build start.

Obviously, in this situation, changing URL parameter in runtime doesn't make sense.

This is done to guarantee that all VCS states at the start build time are as close to each other as possible. Also, this is what it's recommended to share VCS roots among build types and use checkout rules versus using different vcs roots - because different vcs roots (even if they are pointing to the same VCS)

0

Please sign in to leave a comment.