Azure, DevOps and .NET articles

Flux is a set of Kubernetes controllers that keeps your cluster in sync, based on configuration changes you do in a Git repository instead of running kubectl by hand.

A simple Flux setup can be explained with three resources, each one answering a different question:

• where the configuration comes from,
• what gets applied,
• and when to look again.

Let us start with the where.

A forked repository on GitHub is a copy of an upstream repository at a specific point in time. Git does not keep your forked repository in sync automatically, since the upstream repository continues to receive commits while your fork remains unchanged.

In this article, I show you how to sync your forked repository with the upstream repository in the following steps.

Azure has three services that all move messages from one place to another: Event Grid, Service Bus and Event Hubs. In this article we are going to see which one fits better your use case.

In this article, I will start with a simple three-question rule, follow it with a side-by-side comparison, and then explain the differences that actually matter when choosing between them.

Imagine the following GitLab scenario. You open a merge request, push a commit, and GitLab starts two pipelines for it. This is not a bug, it is the default behaviour of the rules keyword, and workflow is the keyword that fixes it.

git config --global user.email sets one identity for every repo on the machine. That’s fine until you push to more than one platform, or more than one account on the same platform.