GitHub pull request triggers not working

Hi! I see two issues:
1. The source branch filter in the Pull Reuquests build feature settings. Instead of the pull request ref, you should specify the refs of the feature branch whose changes you want to integrate into the target branch by creating the pull request (e.g, +:refs/heads/features/cool-feature-1). Otherwise, it is also okay to leave the source branch empty, unless you want to detect only the pull requests from some of your feature branches, but not for all of them.
2. VCS Trigger Branch filter. Instead of the refs +:refs/pull/<number>/head, logical names  should be used as you see them in the branch selector drop-down on the build configuration overview page, e.g.: +:pull/<number>.

I hope that helps!

Hi Anatoly Cherenkov,

Thanks for the hints. I adjusted my settings.

1. The branch specification for the VCS root now contains current release branches. For the moment, I just want to track them, but not trigger builds yet. The specifications is:

+:refs/heads/(master)
+:refs/heads/(1.A.B*)
+:refs/heads/(1.C.D*)
+:refs/heads/(1.E.F*)

Used the parentheses to get nicer branch names in TC.

Only master shows up in branch drop-downs (and my PR), none of the 1.x.y branches are shown.

2. In the pull requests feature settings, I now have

+:refs/heads/my-test-branch-name
+:refs/heads/teamcity*

For the moment, I'm testing with my-branch-name, but I'll probably ask some users to join the PoC and I'm thinking to include branches that start with the "teamcity" prefix. No triggers yet.

3. In VCS trigger settings I now have

+:pull/8773

During the initial phase, I'll have to manually update this to include specific PRs. Later, once we're ready to build all PRs, I'd change that to "+:pull/*".

Actually, now that I think of it, I should be able to use "+:pull/*" right away, right? Cause I've narrowed the branches down to specific patterns in pull request configuration?

With those settings, pushing to my-branch-name does trigger a build, but all the parameters related to branches still show "master". Even `git branch --show-current` is indicating master, but checkout logs indicate the correct revision from my PR branch and that's confirmed by `git log -1`. If I go to the last build configuration in the chain and select "pull/<number>" from the branch drop-down and trigger a build from the webui, in the "changes" section, I do see "pull/<number>", but the build that's triggered runs against master, which is confirmed by git logs and `git log -1` showing latest master. That's unless I explicitly select a revision from the PR branch while triggering, instead of "latest changes at the moment the build is started".

I'm guessing the first part of the above paragraph is still something I'm not fully understanding, but the second seems more like a bug...

Thanks!

Hey Anatoly Cherenkov,

I'd really appreciate a hint here.

When I push to my test PR branch, the build that's started says "Branch: master" on the build page, so something is definitely not working correctly.

All of these say either "master", or "refs/heads/master" in PR builds:

* teamcity.build.branch
* teamcity.build.vcs.branch.my_vcs_root
* vcsroot.branch
* vcsroot.my_vcs_root.branch
* git branch --show-current

Also, these parameters documented at https://www.jetbrains.com/help/teamcity/2022.10/pull-requests.html#Predefined+build+parameters+for+pull+requests don't seem to be available in TeamCity Professional 2022.10.1 (build 116934), which is supposed to be the latest 2022.10:
* teamcity.pullRequest.number
* teamcity.pullRequest.title
* teamcity.pullRequest.source.branch
* teamcity.pullRequest.target.branch

I'd like to do some things conditionally in PR builds and for the moment there appears to be no easy way to distinguish them.

Thanks!

Hi Anatoly Cherenkov,

Thanks again for your response!

> Normally, the 1.x.y branches should be visible in the dropdown after a check for pending changes completes (click Actions > Check for pending changes on the build configuration page).

They're still not visible, even after manually triggering the check.

> However, they can also potentially be ruled out by the build-configuration-wide branch filter (build configuration settings > Version Control Settings > Branch filter).

The branch filter is "+:*".

> Correct.

Changed the VCS trigger branch filter to "+:pull/*".

> Regarding the branches in which the build is triggered, I am not sure if you are referring to a dependency build in a build chain. If so, the dependency build configurations that don't have the branch in which the dependent build is triggered, they will use the default branch. Check if that is your case.

All build configurations in the chain use the same repo and the issue with PRs/branches affects both single builds (e.g. just Init on it's own) and larger build chains.

> Additionally, you can save the full build logs (go to the Build Log page > Download log > select Full build log or Zip) of each of the builds in the triggered chain and send them to us to analyze. You can send them privately by clicking the 'Submit a request' button at the top of this page to raise a support ticket and attach the files there.

On my test branch I ran "git reset --hard origin/master", added one commit on top (1a9196083cdf4a09b422af926fdee08ac3b00e15) and pushed. This triggered the whole chain, but I collected the logs just for Init, up to the second build step. They contain all the git checkout info and output from some relevant commands. I just submitted the logs via "submit a request".

> Lastly, it would make sense to upgrade to the current version of TeamCity (2022.10.1 at the time of writing) if you are using an older version.

As I mentioned earlier, we're already on the latest version and parameters documented as present in that version are not present, so something doesn't seem right.

At /admin/admin.html?item=update, it says "No new versions available, you are using the latest version of TeamCity". And at the bottom of the page, it says "TeamCity Professional 2022.10.1 (build 116934)".

Thanks!

Related: https://teamcity-support.jetbrains.com/hc/en-us/requests/4713309

The branch dropdown only lists "master" and "pull/8773". If I pick "pull/8773", no builds are listed for any build configuration, it just says "no builds". I do see some older notifications in Slack with "in branch pull/8773" though.

Also, I see one of my posts above is still listed ad "pending approval", not sure if that's intentional...

1. The dependent build tries to run the dependency in the same branch as it uses ( pull/<number>).
2. It checks if the pull request branch ref pull/<number> exists in the dependency configurations' VCS Root.
3. Since the branch ref pull/<number> doesn't exist in the dependency build configuration's VCS root, the dependency build is run in the <Default> branch.

Hi Anatoly Cherenkov,

Thanks again for your response.

> Hi! Are you checking those in the snapshot dependency build?

I have one build chain Init -> Build -> Test -> Package -> Release that I want to use for regular builds and PR builds.

The build trigger is on Release and I'm checking the Init build (which is a transitive snapshot dependency) for branch information.

The same issues apply when just manually triggering an Init build and checking it for branch information.

> Is the dependent build building the branch ref pull/<number>?

Well, that's the problem. TeamCity is giving me mixed/conflicting feedback about what it's building.

> Does the VCS root attached to the dependency build configuration have the same branch ref pull/<number>?

There is only one VCS root configured (+1 for the TeamCity configuration).

Its configuration is described in earlier posts - default branch: refs/heads/master; branch specification: +:refs/heads/(master), +:refs/heads/(1.A.B*), +:refs/heads/(1.C.D*), +:refs/heads/(1.E.F*).
 
> If the answers to the above questions are yes, yes, and no, respectively, here is what happens:

The answers would be
* Yes
* I was expecting it to, but it's unclear what's happening
* In what sense "have"? It's the same VCS root throughout the chain

> The dependent build tries to run the dependency in the same branch as it uses ( pull/<number>).
> It checks if the pull request branch ref pull/<number> exists in the dependency configurations' VCS Root.
> Since the branch ref pull/<number> doesn't exist in the dependency build configuration's VCS root, the dependency build is run in the <Default> branch.
> If you need the dependency build to run in the branch whose logical name is the same as that of the source branch in the dependent build configuration's VCS root, you would be interested in upvoting this feature request:
> https://youtrack.jetbrains.com/issue/TW-79593

Building the same revision throughout the chain seems like the most basic, fundamental feature in a CI system.

Are you saying TeamCity is not capable of doing that for GitHub PRs? If so, I'd say that GitHub PRs are simply not supported. Given that GitHub PR support is claimed to be present, I'd say https://youtrack.jetbrains.com/issue/TW-79593 should be a high priority bug, rather than a normal priority feature request.
 
> In the meantime, it is only possible with workarounds. One option would be creating a new pipeline (build chain) for the pull requests and specifying the required default branch in the dependency builds.
> Another option would be to use the teamcity.pullRequest.source.branch parameter to retrieve the name of the PR source branch and then use that name to run the required configurations via REST API: https://www.jetbrains.com/help/teamcity/rest/start-and-cancel-builds.html.

As I mentioned, teamcity.pullRequest.source.branch is not an available property. Autocomplete doesn't complete it and when used in a build configuration, it shows up as a missing property expected to be set on the agent, causing no agents to be compatible.

One of the reasons we want to switch to TeamCity is to avoid baroque hacks to make basic things work. So far the workaround here sounds like a step backwards for us. I'm really hoping there's a misunderstanding here somewhere.

Thanks!

I'd be happy to get on a call to debug this. Please let me know if that sounds like it would help and we could schedule something at a convenient time.

I just updated from build 116934 to build 117025 and the teamcity.pullRequest.* parameters still appear to be missing. Trying to print the value in a build step results in no agents being compatible with the explanation:

"Implicit requirements: teamcity.pullRequest.source.branch defined in Build step: build parameters"

At first glance, all the issues from the previous build still apply, but I'll trigger a full chain again and see. I'll share full logs from that later.

When I push to my PR branch and go to "Build Chains", under Release, it says "pull/8773", but under Init, Build, Test and Package, it says "master", but when I look at the revision being built in Init, it gives me the latest one off my PR branch.

> Since the branch ref pull/<number> doesn't exist in the dependency build configuration's VCS root, the dependency build is run in the <Default> branch.

I think I understand now.

TeamCity will fetch the right revision, but doesn't fetch the PR branch in dependent builds, because the VCS branch specification doesn't cover it.

While that's much less severe than building the wrong revision, this is still a bug, because TeamCity itself isn't aware of what it's building and presents incorrect information in the UI.

Additionally, I need to do different things depending on whether the build is a PR build, so I need to be able to tell what branch/PR is being built in every build in the chain. 

Hi Anatoly Cherenkov,

I managed to implement a workaround for detecting that a PR is being built, so I can do things conditionally based on that. It's an ugly hack, but it unblocked some implementation work for me. That said, I'd need an actual fix before I can present TeamCity to some of our developers. Defining separate build chains, or triggering builds via the API is not a feasible approach. The switch to TeamCity is meant to make things simpler, more dependable, more streamlined, so I really can't afford to resort to hacks for core functionality. I'd really appreciate it if the proper fix for this issue could be expedited.

Thanks!