Shared resource with variable value?

I would like to define a write lock for a resource, but the value of the resource is a variable. For example, I would like to have the following lock defined in multiple build configurations:

teamcity.locks.writeLock.environment = %environment_name%


Is this possible?

8 comments
Comment actions Permalink

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.

4
Comment actions Permalink

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.

3
Comment actions Permalink

Hi,

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

0
Comment actions Permalink

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:
  3. teamcity.locks.writeLock.environment = %environment_name%

  4. Kicked off a Configuration A job with environment_name set to "prod-2".
  5. 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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.
0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0

Please sign in to leave a comment.