Teamcity integration with Azure Devops. (Build Status Validation)

We currently run TeamCity with Bitbucket & JIRA, on premises, however due to these both becoming EOL, We are looking at integration of Teamcity with Azure Devops (GIT), which is already in use elsewhere within the organization.     Currently, we aren't using TFS build and release pipelines, but sticking with TeamCity, as it offers more flexibility.

We have most things working, simply pushing repos and repointing the VCS roots.  However one aspect that is unclear is how Build Validation works.

Within TeamCity, there are 2 build features.

1/ Commit Status Publisher (this is how Teamcity and Bitbucket interact).  This can configured to point at devops and the status is shown for each build whenever a new commit is pushed, and a build is triggered. (in the same was a Bitbucket status publishing)

2/ Pull Requests.   It's unclear what this does, it seems to only trigger a build when a PR is created, it's also unclear how it interacts with the other build feature above.  Understanding use cases for these would be helpful, the docs aren't clear.

 

In addition to this, within Devops, there is a Build Validation setting within branch policies.   This wants me to select my devops pipeline, of which there is  none, as we aren't using devops pipelines.

I'm wondering how with 3x options, we can configure our setup to prevent merges on failed build, which seems like a very key requirement for any CI build platform.

Right now, I'm seeing the following in Devops, “Unable to queue build”, when I have build validation enabled,  I assume this is because no devops pipeline is configured.

Is it actually possible to block pull requests with failed builds uisng TeamCity and Devops combo?   If so, how??

 

Thanks,

 

 

 

0
10 comments

Wondering if “Status Policy” is what I need to use, however the dropdown gives me no hint on what I need to set it to, so it works with TeamCity.  I find it surprising nobody is using CI and not blocking merges of failed builds, as this is surely basic CI.  So how are others configuring Teamcity and Microsoft Azure DevOps.?

0

The dropdown suggests it shows the most recent status pushes to the repo, which I don't think is true, as I am seeing passed and failed status in TeamCity from the commit status publisher.

0

If my understanding is correct, yes, we can enforce the blocking of pull requests with failed builds by leveraging TeamCity and Azure DevOps.

For more information about TeamCity Pull Requests and Azure DevOps Pull Requests, you can refer to the relevant documentation: TeamCity Pull Requests and about pull requests and permissions - Azure Repos.

In TeamCity, we can make use of the Commit Status Publisher and pull request feature. This involves launching each build on a virtual branch, presenting the actual build result after merging the Pull Request. And the build result will be displayed on the Azure DevOps pull request page.

Additionally, you have the option to utilize Azure DevOps branch policies to assign reviewers through Azure DevOps branch policies and settings. This allows manual approval or denial of the pull request by designated individuals.

Regarding Build Validation settings within branch policies, it should just work with Azure DevOps pipelines, offering automated checks before proceeding with Pull Request merges.

We also can get more information about teamcity Commit status publisher and pull requests from TeamCity tutorial - How to send build information to GitHub, Jira etc and TeamCity tutorial - How to work with pull requests.

If these solutions don't resolve your issue, please provide specific details about the problem you're facing. If you've already attempted any of these suggestions, please share the outcomes. Alternatively, you can create an issue in YouTrack  and include any necessary attachments (make it visible only to the JetBrains team) if the information is sensitive and should not be shared publicly.
Feel free to provide your feedback by following this document.  We value your input and appreciate your efforts in helping us improve.

0

So this is where I ended up, and it's a mixed bag.

Commit Status Publisher on Azure Devops won't block or pass a pull request, it merely shows the current build status in the builds.  (this is different to how Bitbucket works).   I also needed to configure the Pull Requests build feature, and this will kick off a build when a pull request is created and will block or pass a build.

The only issue with this, that our builds take a very log time (over an hour), and we end up with a build for the same commit as the build for the pull request, which isn't ideal. 

Is there a configuration in all these options that avoids 2 builds from the same commit SHA?

0

Hi, 

Azure DevOps pull requests feature monitors builds only on the `refs/pull/*/merge` branch. The build system detects requests on a merge branch, not directly on the pull request itself. In other version control systems (VCSs), builds are often triggered based on pull requests. For each build, a virtual branch is created. This branch represents the result of the build after merging the pull request. It includes both the commit with the actual changes and a virtual merge commit. This allows developers to see the impact of the changes once merged. 

When a pull request merge triggers a build and subsequently attempts to merge into the target branch, which is also monitored by TeamCity, it results in another triggered build. This is the expected behavior. However, it's important to note that the commit SHA for these two builds is not the same.

In your situation, it appears that you aim to avoid triggering the build twice. You can make this determination by configuring whether TeamCity monitors the target build.

If this does not align with your scenario, please provide additional details about the two builds originating from the same commit SHA? It would be beneficial to include screenshots of the following settings: Branch specification, pull requests feature, teamcity build result page, Azure DevOps target branch policy, and pull request page. 
Large files can be uploaded via https://uploads.jetbrains.com/. Please let us know the exact id after the upload.

You also can create an issue in YouTrack and include the necessary attachments (make it visible only to the JetBrains team) if the information is sensitive and should not be shared publicly.
Feel free to provide your feedback by following this document (https://www.jetbrains.com/help/teamcity/2023.11/feedback.html).

0

Thanks, I'm still rather confused by these 3 separate settings.  (VCS Trigger,   Pull Request Build Feature,   Commit Status Publisher), there are interactions and dependencies within all of them on each other.

What would be the recommended setup to replicate how TeamCity and Bitbucket work?  In that the last build status of a branch can block a PR (if it failed), without needing to kick off a dedicated build for the merge?   Without using the “Pull Request Build Feature”, the pull request is always blocked.  As soon as I add the feature, it then adds this extra build. It's also dependent on "Publish pull request statuses", without this option checked, nothing happens.

I have made some progress on this, as I do now understand what this feature is doing, it's doing an test merge, and making sure this builds correctly.   This is however mostly pointless, as it just ensures it works at the point in time the pull request was raised, there is no guarantee that someone hasn't merged some code in the meantime that whilst doesn't cause merge conflicts, but could cause build errors.

 

How are other people using these 3 features when using TFS and Teamcity in their workflows?

0

Hi,

> I'm still rather confused by these 3 separate settings. (VCS Trigger, Pull Request Build Feature, Commit Status Publisher), there are interactions and dependencies within all of them on each other.

I understand that you're still struggling with the three separate settings of VCS triggers, pull request build functionality, and commit status publishers. It's true that there are some mutual interactions and dependencies between these settings. Let me try to explain the relationship between them in more detail:

VCS Triggers:

A VCS trigger is a basic build-triggering mechanism used to trigger a build when a change is made in a version control system (VCS).
When any branch or path in the codebase changes, the VCS trigger detects and triggers the corresponding build.

Pull request build features:

The pull request build feature is specifically designed to handle the build of a pull request.
It allows you to trigger a build when a new pull request is created or submitted to a pull request. This helps build and test the code before it is merged.

Submission Status Publisher:

The commit status publisher is used to feed back the status information of the build to the relevant commit or pull request.
When a build is complete, the commit status publisher updates the status of the commit or pull request to reflect the success or failure status of the build.

Interactions and dependencies:
The VCS trigger is the starting point of the build, which monitors the codebase for changes and triggers the build.
The pull request build feature relies on VCS triggers to automatically trigger builds when changes are made in a pull request.
The commit status publisher is the endpoint of the build, and it feeds back the build status information to the commit or pull request, providing the team with real-time build status.

>What would be the recommended setup to replicate how TeamCity and Bitbucket work? In that the last build status of a branch can block a PR (if it failed), without needing to kick off a dedicated build for the merge?

We can get more information about how TeamCity and Bitbucket work from Pull Requests | TeamCity On-Premises Documentation (jetbrains.com) (https://www.jetbrains.com/help/teamcity/pull-requests.html#Bitbucket+Cloud+Pull+Requests) and How to integrate TeamCity CI/CD with Bitbucket - Atlassian Community (https://community.atlassian.com/t5/Bitbucket-articles/How-to-integrate-TeamCity-CI-CD-with-Bitbucket/ba-p/1669294)

Bitbucket Cloud does not create dedicated branches for pull requests, this build feature monitors directly source branches in a source repository (forks are not supported).
If more than one pull request is submitted from the same source branch at the moment of the build start, TeamCity will display all these requests in the build results. However, only commits from the open PRs matching the filtering criteria will be displayed as Changes of the build.
Note that the branch specification of the VCS root must not contain patterns matching pull request branches.

The TeamCity pull request feature automatically triggers a build when a matching pull request is submitted. It appears that no way to define which is the last build status of a branch.

> This is however mostly pointless, as it just ensure it works at the point in time the pull request was raised, there is no guarantee that someone hasn't merged some code in the meantime that doesn't cause merge conflicts, but could cause build errors.

In the product environment, other contributors can review your proposed changes, add review comments, contribute to the pull request discussion, and even add commits to the pull request. After all are happy with the proposed changes, then you can merge the pull request.

I totally understand your concern, and it's important to note that the behavior you're observing is how pull requests function. Pull requests lack a mechanism to automatically detect changes in the target branch. Therefore, if any modifying occurs in the target branch, initiating a new pull request becomes necessary before merging. This is also a reason why we need [approval] action before merging.

0

Thank, I have been referring to those links, however much of the advice given is done so in isolation and doesn't consider users trying to use the pull request feature, and often advice given in the documentation actually breaks the pull request feature.     The area of most pain is the VCS filters, I haven't found a combination which correctly works.


We have given up on the concept of trying to get builds AND pull request builds, and just settled on trying to get pull request build status published correctly, easier said than done..

The only way I have ever had a pull request build get triggered is when the VCS root specification itself is left blank.  Putting anything in the VCS root branch specification breaks triggering.

The issue however is for our release builds that we need a build that is not the result of a “test” pull request, we need to be able to put something in that branch specification to include our release branches in the branch filter in the build plan.

Is this even possible with a single VCS root, or do I need separate VCS roots?   Going round in lots of circles with all of this, so any help with a working setup would be greatly appreciated.

 

Also totally undocumented, is if you want a rebuild to occur when a pull request changes, then you need to tick the  “Trigger a build on each check-in” and  “Include several check-ins in a build if they are from the same committer” options, which doesn't seem to be needed when you aren't doing PR based triggering, you automatically get a build when a commit is made to a branch.

0
Hi,

If I understand correctly, you may find the information on working with feature branches(https://www.jetbrains.com/help/teamcity/working-with-feature-branches.htm) and configuring VCS trigger rules(https://www.jetbrains.com/help/teamcity/configuring-schedule-triggers.html#VCS+Trigger+Rules).
0

After much going around in circles with this pull request feature, which seems to impact every corner of our previously working build plans, and flip flopping between fixing something and breaking something else (e.g. things not triggering), I have something that sort of works.

 

I had to create a VCS Root for every plan, as soon as I started trying to share a VCS root, and filter branches, things would break, branches wouldn't trigger, or dependencies wouldn't build.

The only weird (or perhaps normal?) issue I have, is when there are lots of open pull requests, the pull request is kicked off once for each (other) pull request.  If there are 3 other open pull requests, it appears to be triggering a build against all the other open pull request branches, which seems odd.   Is this intended behavior?   How do I just get it to build the RELATED pull request, not everything that is an open pull request?  I guess this is caused by the +:pull/*/merge  VCS trigger accepting ANY pull request as trigger.

Settings:

VCS Root exclusively for pull requests;

  • Default branch: master
  • Branch Specification:   empty

Build Plan settings exclusively for pull requests;

  • Branch Filter:

                 +:*
                  -:<default>

VCS Trigger:

  • Trigger Build on each check-in  :   enabled
  • Include Several checkins if they are built from the same commiter:  enabled
  • Branch Filter:     +:pull/*/merge

Build Features Pull Requests:

  • By Target Branch:  master

Build Features Commit Status Publisher:

  • Publish pull request statues:   enabled.

 

 

0

Please sign in to leave a comment.