How to use the TC Open API to add a new Dependency?

I've found DependencyFactory.createDependency and SBuildType.addDependency; however, I'm not quite sure how to create a DependencyFactory. Is this initialized just by adding a bean to my application context:

  <bean id="dependencyFactory" />



I didn't see a reference to the implementation class in the javadocs, so wasn't sure what the "correct" way to do this is. Any suggestions would be greatly appreciated!
5 comments

Sankalp,

The factory is available via Spring autowiring. e.g. try just requesting the bean in the constructor of your Spring-defined bean.


BTW, can you share what kind of plugin are you working on?

0

Ah! Yes, I should have realized that, thanks.

As for what I am trying to do: I'm actually extending the existing REST plugin to provide a project/vcs "clone" facility that we can consume from scripts. The ultimate intent to provide a full release process automation mechanism.

Originally, our team was using a different CI product, and at the time, we'd had some scripts that only handled the VCS aspect of the release process (i.e., creating the appropriate branches in our Subversion repository, updating POM version numbers, etc.). The previous CI product was quite a bit more simplistic, so we never actually bothered to create new sets of build configurations for our branches. However, with TeamCity, a lot more automation now became possible, and I wanted to not only have the CI server create the branches, but also have it create the appropriate build configs for the newly created release branches.

My initial strategy was to basically offer a few REST endpoints for creating projects and copying build configurations and their associated VCS roots. However, this proved to be insufficient; since we have a complex set of dependencies and a few build triggers also defined from our "trunk" project in TeamCity, creating copies of those configs results in the new configs' dependencies pointing at configs from the trunk project, and NOT at configs in the newly created branch project. So for the next cut of our plugin, I wanted to add a few more REST endpoints that would allow us to create a new set of dependency rules for the branch project that follows the same dependency graph as we have defined in our trunk project.

Ultimately, my end goal is to be able to use TeamCity itself to provide a one-touch release process that will automagically create the branches in Subversion, create a branch project and associated build configs in TeamCity, and then run the release build itself.

0

Sankalp,

Thank you for the description!

Actually, we are thinking on adding somewhat alike features to TeamCity (release, branch), but so far we do not have exact vision on how the feature can be implemented to suit many varying needs.

If you have ideas - you are welcome to share them!
You can post into threads in this forum or comments into relevant/new issues in the tracker.

0

Yegor,

To be perfectly honest - I think all you'd have to introduce in TC would be two fairly simple features: a) multi-level template "inheritance" and b) VCS root templates. Let me explain what I mean.

In our team's use case, we have a highly componentized product, in the sense that the various pieces of the product are Mavenized into their own modules and such. We then have an assembly process that builds the final product from all of the other components. Additionally, in source control, each component is separated into its own root location. Since we're using Subversion, this means we've got something like the following:

svn_root/
   componentA/
      branches/
      tags/
      trunk/
   componentB/
      branches/
      tags/
      trunk/
    ...




Now, of course, one can argue the merits and problems with such an architecture; however, we weren't really in a position to change our infrastructure quite that much. So I had to find a way to make things work smoothly in TeamCity as-is.

First off - I've been using TeamCity since 3.x (at a previous job), and when I started in my current role, my first suggestion was to migrate to TeamCity. This meant I got to use 5.x for the first time, and when I first played with build config templates, I was absolutely thrilled. Templates hugely improve management of projects! What I chose to do is basically use a single generic template for all of our configs, while making extensive use of build config parameters and properties to properly parameterize each component's build config. However, this meant that I wouldn't be able to store VCS information in the template.

What I would have ideally liked to do to support our branch/release use case was to make "sub-templates," that would derive from the base template for a given project. Then, I could just create derived templates from my base template - one for each component - and then create the actual build configs themselves from those base templates. I could also specify things like dependency relationships and build-config build triggers within the derived sub-templates. This would have almost completely eliminated my having to write a plugin to expose the various REST endpoints for cloning VCS roots, dependencies, etc.

I say 'almost', because the one other feature that I'd need to have would be a way to parameterize VCS roots, by templatizing them much like you do with build configs. With the ability to parameterize the VCS roots as well, I could then effectively have a "trunk template," a "branch template," and a "release template" for both build configs and VCS roots, and then, my project management would be a snap; I'd just need to supply the appropriate parameter value(s) to properly "instantiate" a build config.

If you'd like, I can open issues for these in the tracker?
0

Sankalp,

Thanks for the thoughts, we do appreciate the effort.

Some feature requests in the tracker so that you can vote if you did not already: support variables in VCS roots and nested build templates.

BTW, if you use Maven extensively, we are open to suggestions as to improvements in TeamCity Maven support. We do not use Maven a lot ourselves and need some feedback on the most necessary features/biggest pain points from real Maven gurus...

0

Please sign in to leave a comment.