TeamCity dream feature

Hello JetBrains TeamCity team!

You've asked for dream features in the dev blog (http://teamcitydev.blogspot.com/2012/05/teamcity-703-bugfix-fixes-and.html). If I absolutely had to pick one: http://youtrack.jetbrains.com/issue/TW-5884. It has 32 voters over the past 3 years. The lack of this feature complicates TeamCity management to the point where we have to create new projects just to take away permissions from some users that should not run a particular build or see the changes. We've been waiting for this foreveeeeeeeeeer.

Many thanks,
Oleg.

8 comments

TW-705 (grouping projects), or generally a way to organize both build configurations and projects in some grouping way would be quite important. I currently use naming conventions to group build configurations into sensible batches, but that's very fragile.

0

Oleg,
Christian,

Thank you for the input!
We will certainly consider both feature for the next TeamCity major (8.0, probably to be released in the first quarter of 2013).
Per-build configuration roles seems to be quite simple in terms of user-facing logic (but still requires a bit of effort to implement).
On the other hand grouping will probably require more discussions as to how that will be used, where supported, etc. A good place to collect use cases for that is comments of TW-705 itself.

0

The feature 'Execute a build step based on a condition' (TW-17939) would add some amazing features to the system.  It would allow one master build script that could be easily run differently based on build parameters.

0

Just out of curiosity... why not test for the parameter in the build script?

I actually don't like the idea of placing too much logic in the TeamCity build runner, preferring to place it in a script under the same version control system as the code you're building. This reduces the number of places that need to be audited or watched...

0

Hi

Another deature that would be good for Admin purposes would be TW-15251 Allow to specify separate paths for potentially large directories under .BuildServer. We have a range of network storage devices which i would like to use to store artifacts on and keep everything else on the local machine.

pod

0

That's an interesting topic that we also have some internal discussions about: should the build execution logic be partly present in TeamCity (configured with web UI, etc.) or only be stored in the various build scripts?
At this time we definitely do not way to make a visual build tool out of TeamCity (if any, that should probably be a separate product not bound to a build server).

However, where lies the boundary between convenience of doing certain configuration inside TeamCity and making the build not possible without TeamCity is still to explore.

0

Pardeep,

Do you just want a convenient way to achieve the same effect as OS file link can be used for or are you after something more intelligent?
We can discuss that in the comments of the issue.

0

Here's another utility (now owned by Microsoft):
http://www.microsoft.com/technet/sysintern...k/Junction.mspx

Also...see the note on that page:

Quote

Note that Windows does not support junctions to directories on remote shares.

That's probably why your command wasn't working. You have to create the junction to a mapped drive. So you were doing this:
linkd D:\data \\myserver\globaldata

Where you should've mapped \\myserver\globaldata to a drive letter (such as G: for example) and used the following syntax:
linkd D:\data G:\

Hi

I guess your talking about using junctions however it suggests I have to map a network drive. Which cannot be seen if you are starting teamcity as a service from windows.

0

Please sign in to leave a comment.