Build Type Name from Build_Type_Id

I realised today that I accidently posted this in the General Disscusions instead of the Plugin Development.  So I am moving it to here.

== Original Post ==

I was wondering, is it possible to get the Name of a Build Type with just the Build_Type_Id?

To elaborate on what I am trying to do:
I am writting a custom plugin for internal use that has additional information in the Database.  This information is tied to Build Configurations (aka Build Types).  I am suspending a build until I get this additional information, and I wanted to have a new table on the queue page which will direct users to another page to fill out the information.  All of this is working.  The issue I am running into is that the Name of a Build Configuration (and it's related Project) are not stored in the Database from what I can tell, so I cannot just write queries to tie it all together.  I know that I would be able to get the Name from an object of type SBuildType or BuildType, but these are typically only available when an action takes place (such as a change to the VCS being detected).  Is there a master collection of BuildTypes that I could pass in the Build_Type_Id to and get back the BuildType object that matches similiar to the Notifiers (even if I need to iterate over the list to find what I want)?  And if there is, would this collection be available directly in a JSP file, or would I need to do the work in the Controller and pass the result to the JSP as a parameter?

Thanks,
~Alex

5 comments
Comment actions Permalink

Alex,

You can use:
ProjectManager.findBuildTypeById (get ProjectManager via Spring)
You can also get all build configurations via ProjectManager.getAllBuildTypes

Seems, you can prepare list of BuildTypes in the controller and pass it to JSP for usage.

As a side note, please note that the tables you created in the database are not covered by TeamCity backup functionality, so you might need to establish manual backup.

BTW, Can you please describe the original use case that you are solvimg? Might TW-7652 be related?

0
Comment actions Permalink

Yegor,

We currently have a test server were all of our functional tests are being run.  Our end goal is to have a build be pushed to that server as soon as a change is made on our VCS root.  However, our current process to get a build onto the test server requires more information about the changes to VCS than are provided in the comment field.  These include things like which issue(s) the changes are related to in our bug tracking system, whether or not an IIS Reset will be needed, etc.

The link you provided to TW-7652 appears to only be useful for build properties already in TeamCity.  Additionally it sounds like it only works for a manually initiated build (although that may not be the case, as those properties are still required).

The way that I am achieving the main chunk of functionality is a modification of the buildQueuePause example.  The canStart method gets called by each build in the Build Queue (which is not what I assummed looking at your example the first time around) and instead of just having a simple variable that can be toggled, it goes into the Database and sees if the additional required information has been filled out.  The user can't set the value directly, it's all conditional on the additional information being in the databse.

After that was in place, I needed to allow the user to enter this information.  For that I have a PageExtension hooked into the PlaceId.CHANGE_DETAILS_TAB which is a web form to fill out and modify this additional information.  I also have a custom listener that will send an email to the person who made the VCS change with a link to the PageExtension associated with the change (you may remember me asking questions about that too).

And finally I am extending the queue page to show which VCS changes still need information in order for the build to progress, along with links to where a user can fill out that information.  This is more for our project lead so that he can see who is holding up the build.

Thanks for all your help,
~Alex

P.S. The ProjectManager looks to be what I'm looking for.  I will mess around with it today.

0
Comment actions Permalink

For the sake of posterity, here is what I did to achieve what I wanted.

In the class that is extending the Queue page, I added the ProjectManager to the constructer and store it in a static variable.  I then created a static method that takes the Build_Type_Id as a parameter and uses the ProjectManager to get the full name.  Then I just call this static method from the JSP.  Works exactly how I wanted it to.

== Code (Only the relevent code is shown) ==
import jetbrains.buildServer.serverSide.ProjectManager;

private static ProjectManager _projectManager = null;

 public QueueExtension(PagePlaces pagePlaces, ProjectManager projectManager)
 {
     ...
     _projectManager = projectManager;
 }



 public static String GetBuildName(String buildTypeId)
 {
      String buildName = "{Could not find build name}";  //Initialized to an "error" message.
 
      if (_projectManager != null)
      {
           jetbrains.buildServer.serverSide.SBuildType buildType = _projectManager.findBuildTypeById(buildTypeId);
 
           if (buildType != null)
           {
                buildName = buildType.getFullName();
           }
      }
 
      return buildName;
 }

0
Comment actions Permalink

Alex,

Thank you for describing your case and summarizing the solution to the original question.

A small note: I'd consider making canStart methid as fast as possible, rusing some cached data. Database lokkup and other potentially long operations can probably be done in background and supply data for the canStart to use.
Otherwise queue processing can become slow and there can be builds that have nothing to do with the logic, but still waiting in the queue until all previous queued builds get their data...

0
Comment actions Permalink

Yegor,

I was worried about querying the database as frequently as the canStart method seems to be.  So what you are suggesting is to have an extra variable that the canStart method actually checks, but then periodically update (based off of the last time it was updated) this new variable?

Currently everytime the canStart method is called, it's making checks against the database.  If I'm understanding you correctly, this new way would effectively slow down how often the canStart method hits the database.  The tradeoff obviously being that it may not start the build immediately, but it will within the cache update time.

== Psuedo-code ==
bool cachedCanStart;
DateTime cacheLastUpdated;

canStart()
{
if (GetCachedCanStart())
...do build...
else
...wait...
}

GetCachedCanStart()
{
  if (cacheLastUpdated more than a minute ago)
  {
    cachedCanStart = getInfoFromDatabase();
    cacheLastUpdated = Now;
  }
  return cacheCanStart;
}
===============

As a side note, from my testing it seemed like even if a build was not on top of the queue it would still build if it could and all other builds above it were not able to be built.  I would have to try it again to know for sure.

0

Please sign in to leave a comment.