SonarSource made a great improvement, it will now show conditional coverage of your tests. Unfortunately, when using the pipeline as described in my previous blogpost, SonarCloud reports way too many conditions. For instance, a simple
if(condition)would result in 10 possible conditions which clearly is incorrect but easy to fix.
Creating an Azure DevOps pipeline for .NET Core with multiple test projects, SonarQube, ReportGenerator & more
Update: A followup blogpost improving on this pipeline is available here!
After having to configure another pipeline at a customer for a .NET Core project with multiple test projects and wanting test results and code coverage nicely visible in both Azure DevOps and SonarQube, I decided it was time to write the whole thing down for others to use. While there are some really nice blogposts out there all dealing with parts of what I wanted (like this one or this one or this one by my colleague Niels Nijveldt), I didn’t find one that combined all of it, so here we are.
My colleagues and I share a lot of knowledge, from helping out customers, to writing blogs), speaking at conferences and last but not least: we have our own magazine. If you haven’t received a printed copy somewhere, you can always download the PDF here.
Some of the articles are also available directly at this page and as this is my own blog ;) I’ll highlight one of the articles I wrote together with our Azure Functions expert Marc Duiker in magazine number 7:
A while ago a customer really wanted a solution based on Python. We already decided on Azure Functions, but Python support at that time was still in preview. I decided to evaluate exactly how preview it was. The result wasn’t really pretty: I didn’t get things to work in Azure, we gave up and told the customer we really needed to stick with C# for the time being. You can read all about it in this blog post.
Python support is still in preview, but on the one hand I know that the team has been working hard to improve things and on the other hand, the Azure Functions v2 runtime has reached the “general availability” status which should mean that it’s production ready. So time for round 2, let’s see how things turn out this time.
Recently I helped Rob Bos by creating an ARM template, that allowed him to spin up a VM in Azure and which would host a Chocolatey Server. Rob wrote a nice blog post about this. As he mentions in his post, there are still some issues with the ARM template. On major thing is fixed though: The DSC step no longer fails and it’s no longer necessary to manually execute PowerShell. Here’s how I fixed it.
Update: Others, like Jeff Hollan, have been able to get am Azure Function working with Python. He did have to change something in the requirements.txt as well, same as I mentioned here. Have a look at this GitHub issue. I’ll give it another shot myself soon. Update: Read about my second attempt here
Googling led me to a couple of blog posts about Python on Azure Functions. Those led me to believe Python on Azure Functions is using Windows as OS, uses a very old Python version and is very slow. Even Microsoft’s own Azure Functions Supported Languages is stating Python isn’t supported on runtime 2.x.
Finally, I went to the Azure Functions Python Worker GitHub page and read something a little more inspiring: Python 3.6, Linux and the 2.x runtime :-) I decided to give it a try on my Windows 10 machine with Visual Studio Code. Here is what I did and what my experience and result was like.
Joining Xpirit has opened up a lot of cool possibilities for me, like being able to visit conferences as Build or NDC. So let’s talk about my first visit to NDC Oslo, 13-15 june 2018.
So! Time to write my first blog. Something simple first, guess I need a few posts to get into this. Judging by the amount of blogs, I’m probably not the first one starting out and probably won’t be the last so I thought I’d share what I did to set up this blog.