.NET Core build chain questions

Preface: I read https://teamcity-support.jetbrains.com/hc/en-us/community/posts/115000112944-Building-dependent-net-core-projects and got some good tips from it.

We have two build configurations for a .NET Core application. The first builds and runs tests on a Windows agent. The second takes the compiled artifacts from the first build and runs the tests on a Linux agent. (We aren't able to actually compile the application in Linux yet but the binaries work.)

The first configuration runs on a VCS trigger on any branch so it builds on every Git pull request. The second is runs on a Finished Build trigger based on the first. The second also uses both an artifact dependency (to get the binaries) and a snapshot dependency (required for the finished build trigger). The artifact dependency uses "Build from same chain". This configuration also does NOT have any VCS settings configured since it doesn't pull anything from source control

Question 1: Is this the proper way to set this up? Or should I configure VCS settings on the second one and trigger the build based on snapshot dependencies as outlined in the article above (again, bearing in mind, it doesn't actually pull anything from source itself).

Question 2: We also use "Report status changes to GitHub" for most of our builds and it works great for regular non-chained builds. Is it possible to configure it to report the status to GitHub for both configurations? I.e. if the first build fails (for the Windows .NET core config), it would report that to the pull request on GitHub. If it succeeds but the second build fails (for the Linux config), it would also report that back to the same pull request.

0
4 comments

Hi Kyle,

I'll try answering the questions:
1- While it's correct, finish build trigger + snapshot dependency is redundant. The recommended approach is to leave the VCS Root where it is, but move the VCS Trigger. The VCS Trigger can be set in a build without VCS Roots, as long as you mark the "Trigger a build on changes in snapshot dependencies". That way, it will automatically trigger the initial build and you don't need the finish build trigger on top of it.

2- I'm assuming you mean the Commit Status Publisher build feature? If that's the case, it's configured in a per-build basis, so you would probably like to put it at the end of the chain, or wherever part of the chain you want to get reported.

Hope this helps.

0
Avatar
Permanently deleted user

Thanks Denis. That helps. I've set up the build according to #1 now (based on your documentation as well) and it is indeed reporting the status on the GitHub PR.

There's one minor inconvenience. The PR doesn't actually indicate that the build has started until the Linux configuration is running. I.e. when the Windows .NET Core build is running, the PR still says that it's waiting for the status to be reported from GitHub. It doesn't actually show anything is running until the Linux build starts. It would be nice if the status on the PR showed that the dependency build was running so that we could get a link to it at that time.

0

Hi Kyle,

the solution to that could be to have it in all builds in the chain, although that is a bit cumbersome and at some points could show conflicting information (such as it being finished when the first build finishes, then moving back to running, etc). It's not currently possible to apply it to a full build chain.

0
Avatar
Permanently deleted user

Thanks Denis. We've already set that up as a work-around and it's actually quite handy to know exactly which build caused the failure at a glance.

0

Please sign in to leave a comment.