Way to access vcs root that triggered the configuration

Hi,

We have a workflow which includes dynamicaly created projects (via rest apis) that requires identical build configurations.
All project have their own git repositories.

Since the build configurations one could create with teamcity is limited and subject to payment,
and we may end up with hundreds of projects since they are dynamically created,
approach we choose to go is, just one configuration with multiple vcs roots.

though, albeit configurations are identical, paths they are operating on supposed to change for each vcs root.
And in my build step, which is a command line script, I need to know name of the vcs root that triggered the build,
so that I can move and copy files accordingly.
I looked at checkout rules and tried to give each vcs root a different checkout directory,
but this did not help me achieve the behaviour I was looking for.

I can simulate this behavior with creating a new teamcity project for each of my projects,
and access env.teamcity_project_name variable in my build step. but then again this is subject to payment.

I am open to suggestions,
Thanks in advance!

2 comments
Comment actions Permalink

Hi Berat,

At the moment t is not possible to get information about the VCS root that trigger the build inside build script.
The workflow with one project and many VCS roots is not recommended. In this case you won't be able to see the build statuses of specific project and statistics.
Could you please describe your setup in more details? Why do you need to dynamically create so many projects?

0
Comment actions Permalink

Hi Alina,

Thanks for your response.
These projects are little widgets that are identical in structure and generated via tooling (their remote repositories and ci configurations included).
We have lots of widgets and each of them have lots of builds for every customer.
Rather than complicating codebase, we choose to seperate the codebase for each variation and automate the common legwork.

So all these widgets can be built the same way using the same build configuration,
Only thing different from build to build is, the path that widget supposed to be deployed. and that is name of the widget.
Copying a project with its build configuration for each new widget helps, because I can use the project name parameter in the build script.

0

Please sign in to leave a comment.