The art of simplicity

Yesterday I showed you how to create a new release in Github manually. This was a good starting point as it introduced the different elements of a release and the options we have. Today let us automate the process of creating a release on GitHub using GitHub Actions. Create a new release using Github Actions Go to Actions inside Github and click on new workflow . We’ll not use an existing template but instead choose to setup the workflow ourself : Paste the following yaml content in the editor screen. I’ll explain it afterwards… Explanation of the Workflow name: This is the name of your workflow. You can name it something like "Release". on: Specifies the event that will trigger the workflow. In this case, it’s triggered by a push to a tag that matches the pattern v*.*.* (e.g., v1.0.0 ). jobs: This defines the job that will be run by the workflow. runs-on: Specifies the environment where the job will ru

Being new to Github I decided to write a few post on how to create a new 'release' in Github. I'll start with a 100% manual approach(this post) and will continue with other posts showing a more and more automated process. But today we'll start simple and focus on creating a release by hand. This allows me to introduce the different elements that we can configure when using releases inside Github, knowledge that will be useful later when we go the automated route. Let’s dive in… Creating a new release (manually) Before you can create a release, make sure you are signed in to your GitHub account. Navigate to the repository where you want to create the release. Once you’re in the repository, click on Releases on the right of the list of files.   On the Releases page, you’ll see a button labeled “ Draft a new release .” Click on it to start creating your new release.   The first thing you need to do is to assign a tag to your release. A tag is usuall

Azure DevOps is the SaaS(Software-as-a-Service) version of Azure DevOps Server(the on-premise alternative). As with most SaaS solutions, certain limits apply. Some are operational limits placed on work tracking operations and some are object limits. In addition to the specified hard limits on specific objects, some practical limits apply. All of these limits are documented . but only operational limits like pipeline usage and top commands can be monitored directly in Azure DevOps through the Usage tab . However, object limits—such as the number of projects, dashboards, or teams—have not been traceable so far. With the latest update you can now see the object limits both at the project level: Go to Project Settings and scroll down on the Overview tab: As at the organizational level: Go to Organization Settings and scroll down on the Overview tab: Nice! More information What is Azure DevOps? - Azure DevOps | Microsoft Learn

One of the main design principles we follow when building a GraphQL API is to maximize backwards compatibility. To avoid unexpected breaking changes, we have integrated GraphQL Inspector into our build pipeline. After upgrading to HotChocolate 13, the schema comparison started to fail: It complains that the defer and stream directive are no longer there. And indeed if we open up the schema before the upgrade: And compare it to the schema after the upgrade: We can see that the 2 directives are no longer there. We can easily fix this by re-enabling both directives in our GraphQL configuration code: Remark: If you are paying attention, you can see that there was another breaking change regarding the cost directive. More about that in the following post . More information GraphQL Inspector (bartwullems.blogspot.com) Migrate Hot Chocolate from 12 to 13 - Hot Chocolate - ChilliCream GraphQL Platform

ADFS has the concept of claim rules which allow you to enumerate, add, delete, and modify claims. This is useful when you want for example introduce extra claims (based on data in a database or AD) or transform incoming claims. I wrote about claim rules before but I want to give a heads up about some of the lessons I learned along the way. Lesson 1 - Claim rules can be configured at 2 levels There are 2 locations in ADFS where you can configure claim rules. The first one is at the level of the relying party: The second is at the level of the claims provider: If you don’t know what either is, a short explanation: In Active Directory Federation Services (ADFS), a claims provider is the entity that authenticates users and issues claims about them. This can be Active Directory but also another IP-STS. A relying party is an application or service that relies on the claims provided by the claims provider to make authorization decisions. Essentially, the claims provider verif

Yesterday I talked about Log Parser and Log Parser Studio as tools to help parse files(in my case IIS log files). I was struggling to find a way to parse IIS Log files with custom fields in Log Parser Studio. I solved it by directly calling log parser. However after writing my post yesterday I continued experimenting a little bit and I noticed that when I changed the log type from IISW3C logs to W3C logs, Log Parser Studio was able to process the files and return results.   I don’t know why I didn’t try this before. But the good news is it works!