* If you're running your OSS project on TeamCity at CodeBetter, you now have this plugin available.
Once that's installed, we can now display build status information on the GitHub pull request by adding a Build Feature to our Build Steps:Īnd filling in some simple configuration parameters:Īnd with that, we can see the status on the Pull Request page on GitHub.
TEAMCITY BUILDS INSTALL
To install it, download the plugin as a zip file and place it in the plugins folder of the server and restart the server. This plugin, written by Eugene Petrenko uses some hooks GitHub provides to add notification information on the Pull Request page. In order for this to happen, we do need to install a plugin for TeamCity which currently doesn't ship out of the box. However, there is one other thing that we can do: see the result of the build on the Pull Request page on GitHub. In addition, TeamCity also provides us with a Dropdown, where we can filter all the different pull requests:Īs this is a normal build, like any other build, we can configure TeamCity to receive notifications via email, tray icon, etc, both on successful builds as well as failed builds. With TeamCity now indicating whether this was a merge or head: For that, we can specify the following in the Branch Specification Now, we can actually make this a bit nicer by allowing us to see whether the particular request was the result of a merge or just the branch itself. Where the number denotes the pull request. The result of these builds show up in TeamCity like so: So to recap, adding merge builds the result of the merge, and adding head, just the pull request without the merge. If we want to build the branch, without merging, we could use the following: This means that when TeamCity builds, it will build the branch that was merged. The * refers to ANY pull request, and the merge indicates that we're interested in the pull request merged with the master branch. In this syntax, pull refers to the pull request. What we're saying to TeamCity is to monitor this branch, in addition to the main branch. When a pull request is made, GitHub automatically creates a reference that holds the pull request as well as one that is a merge with the master branch. Let's see what this means and why it works. It actually only requires one thing: configuring the Branch Specification under the VCS root: Setting up TeamCity to do this is really simple. This will drastically improve the workflow since we no longer have to manually create a local branch of the pull request, check it, build it and only then merge it. And I want this to happen without me having to configure every single fork as a repository in TeamCity, because like that, it wouldn't be manageable. What I want to do is have TeamCity automatically build all Pull Requests for me of my main repository, and notify me if it is successful. *This applies to non-OSS too Automatically Building All Pull Requests And what's even nicer, is that it's also possible with TeamCity. Well, luckily for me, and my ability to continuously interfere in conversations, Yet you still need to make sure that it builds and all tests pass. That's a pain, specially if you do a quick code-review and things look decent. I know what I'd like to do, and GitHub makes it so so tempting:īut unfortunately I go with the second option. What do you do? Well, what is it going to be?
0 kommentar(er)
