Shared resource with variable value?

Hi,

Yes, it is possible with "Resource with custom values", where custom values can be set as parameters.

I think I tried this - no luck. Here's what I did:

1. Create a Shared Resource ("environment") with custom values ("prod", "prod-1", "prod-2", "dev1", "dev2", "dev3") at the project level.
2. Added the following configuration parameter to two build configurations:

teamcity.locks.writeLock.environment = %environment_name%


3. Kicked off a Configuration A job with environment_name set to "prod-2".
4. Kicked off a Configuration B job with environment_name set to "prod-2".

At this point I was expecting the Configuration B job to queue until the Configuration A job had finished. Instead, it ran immediately.

Hi,

No, it is impossible to define teamcity.locks.writeLock.environment as build parameter. You need to add build feature for build configuration.

Not sure, but may be this will help in your case. You can set %environment_name% as shared resource custom values (instead of "prod", "prod-1", ...) and add build features to build configuration to lock it. If you run build with environment_name set to "prod-2" then teamcity.locks.writeLock.environment will be equal to "prod-2" and configurations won't run simultaneously.

Thanks for the suggestion, but this didn't quite work either. It looks like %environment_name% is not being resolved before the build is added to the queue (although it appears to have been resolved correctly after the build started running). Here's what I tried:

1. Create a Shared Resource ("environment") with one custom value ("%environment_name%") at the project level.
2. Added a Shared Resource Build Feature to Build Configuration A and B locking the %environment_name% value of the "environment" resource.
3. Kicked off a build of Configuration A with environment_name set to "prod-2".
4. Kicked off a build of Configuration B with environment_name set to "prod-2", expecting the job to be queued.
   
5. SUCCESS: Saw that the Configuration B job was queued because of the "environment" shared resource.
6. Canceled the Configuration B job.
7. Kicked off a new build of Configuration B with environment_name set to "dev1", expecting the job to not be queued.
   
8. FAILURE: Saw that the Configuration B job was queued because of the "environment" shared resource.

Yes, you are right. It won't work. Parameters are resolved later. I think now there is no possibility to configure it this way.
We have a feature request to add REST API for shared resources - http://youtrack.jetbrains.com/issue/TW-36619. Please vote or feel free to create new feature request.

This feature would be very useful in the following scenario:

A build configuration covers several branches, where each branch should be allowed to build simultaneously to the other branches. The same branch should NOT be allowed to build more than one time, but there is no control over this.

Defining a custom Shared Resource with branches as values, would make it possible to limit a single branch to exactly one build.

The exact scenario that Bo Sorensen describes.

We had a setup where each branch (of a total of 2) had its own TeamCity project for their pipeline. We now moved to a higher number of branches that have their own CI pipelines, this has become unfeasible. We moved to a single, multi-branch project, and now face the same problem. Locks work across all branches, although they have nothing in common - own environments, separate build agents...

Being able to create a Shared Resource named 'Regression_%branch-name%' would be ideal for our needs.

Hi Bo/Vladimir,

please, as mentioned by Alina, comment on the issue tracker or create a new one. I'm afraid that continuing to post in this thread will not help getting it implemented.