How do I find if a specific build config has been run on a specific revision?
I - have a fairly simple question, for which I've been unable to find an easy answer, using the TeamCity UI:
Has a build on this specific git revision been done for this specific build config?
Is there any way to do this, through the UI? (Ie, without having to write a custom script that uses the REST API?)
What I've tried:
Filtering the Build Overview Page
If I simply got to the build overview page for the build config in question, ie, https://my.teamcity.server/buildConfiguration/project_and_build_config_id?buildTypeTab=overview&mode=builds, then the options for filtering the builds seem pretty limited - I can filter by branch, tag, or build status... but couldn't find a way to filter by git revision.
Using the Search page
I then tried to use the general search page - I was initially hopeful, because the advanced search syntax seemed to have support for specifying the revision, project, and config. Unfortunately, the fact that you can't do an `AND`, except for the same type of filter, seems to be defeating me. Note that this is a VERY active build config on a very active TC server, so I really need to be able to filter the results.
Assuming that:
- the git revision is 7ade62a137e981fad5122be0e0bded360646fac6
- the first 8 characters, 7ade62a1, appears in the build number
- The config display name is "testing - level 3"
- The full config id is "My_project_TestingLevel3"
Here's some of what I tried:
- "testing - level 3" 7ade62a1
- "testing - level 3" 7ade62a137e981fad5122be0e0bded360646fac6
- +"testing - level 3" +7ade62a1
- +"testing - level 3" +7ade62a137e981fad5122be0e0bded360646fac6
- configuration:(testing - level 3) revision:7ade62a137e981fad5122be0e0bded360646fac6
- configuration:(testing - level 3) revision:7ade62a137e981fad5122be0e0bded360646fac6
- +configuration:(testing - level 3) +revision:7ade62a137e981fad5122be0e0bded360646fac6
- c:My_project_TestingLevel3 revision:7ade62a137e981fad5122be0e0bded360646fac6
- +c:My_project_TestingLevel3 +revision:7ade62a137e981fad5122be0e0bded360646fac6
- ::My_project_TestingLevel3 revision:7ade62a137e981fad5122be0e0bded360646fac6
- +::My_project_TestingLevel3 +revision:7ade62a137e981fad5122be0e0bded360646fac6
All these either gave too many results (ie, included the wrong build config or builds against the wrong revision, or both), or no results at all.
(Note - one possible complicating factor is that this TC server also has a project named like "foobar - testing / level 3", all of whose configs seemed to show up when I did a text search for "testing - level 3".)
Please sign in to leave a comment.
Hi! You can find it in web UI by doing this:
Thanks for the response!
Unfortunately, I tried this and it didn't work - I got 0 results:
And I know there actually is a job, because I copied the revision from it's build page:

It won't be easy to answer this question because TeamCity does not have the entire commits graph. It only knows about the commits which were made after the TeamCity VCS root was created.
Also if the commit is quite old (was made more than 3 years ago) then it won't be able to find it through the user interface.
If you're absolutely sure that TeamCity detected this commit at some point and the commit is not so old, then you can also try to search for it on the Change Log tab of the project where the VCS root belongs.
The commit I'm querying about is definitely known by TeamCity, as it did, in fact, launch a build for it. And the commit was only a few days old (but the particular build config is VERY active at my company, so a few days old means 5-6 pages back in the results).
If I go to "Change Log" for the project, as opposed to the Build Config, then depending on the project, it either says "There are no changes found", doesn't have a search filter, or the search filter returns no results when I put a hash in the "revision" field.
it you are still facing this problem, does it replicate regularly or did it only happen with some build or subset of builds/revisions? Could you also confirm if it also happens with the old UI? It should have the same behavior, but just to make sure.