Are you building Pipelines and unsure about the best way to test and iterate over them? Worry not. Your questions are about to be answered!

In this blog post, you will gain insights into how you can get faster feedback on your Pipeline development by:

• Running the pipeline stage locally
• Running automated tests
• Testing imperative actions
• Running the stage as a container

We will also look into how to more effectively run system-level tests by

• Populating the image cache
• Setting the image pull policy
• Automating end-to-end (e2e) tests

Click "read more" below to continue!

The newly released version of the SKE Backstage plugins will no longer rely on a Git repository to perform CRUD operations on the Kubernetes Cluster. Instead, they will now use the Kubernetes API to manage the resources directly. This enables users to get the most up-to-date information on their resources, as well as manage resources created via other means, like via kubectl.

One important aspect is that you can now use the plugins with OIDC providers, allowing you to have finer control over the authentication and authorisation process.

In this blog, we'll go through the process of setting up your Kubernetes Cluster with Keycloak, and configuring Backstage to use it for authentication. We will then configure the SKE Backstage plugins to use the OIDC token provided by Keycloak.

As much as we would all like, rolling out updates to any software can result in some bumps along the way. This applies to updates to Promises too but Kratix has some feature to help identify any issues within your Promise spec, your Promise workflows and the scheduling of documents outputted by your workflows.

In this blog post we'll explore some of the common issues that users experience when configuring Kratix and developing Promises and well as how Kratix tries to steer you in the right direction when something goes wrong. We'll be exploring:

• Querying Kratix effectively with labels
• Debugging scheduling issues Kratix
• Getting information from Destination and State Store status updates
• Validating the Kratix Promise spec

Click on "read more" to continue!

So you read the guide on Compound Promises and tried out the Workshop, and decided that a compound promise is the right abstraction to expose in your platform. You are about to start writing it, but you are still wondering how you would really go about writing one.

We hear you.

In this blog post, we will build a Compound Promise from scratch. Consider this the ultimate guide on how to build compound promises effectively.

You can follow this guide and build the Promise along with us, or you can use it as a reference when building your own Compound Promises. The Promise we will build is available here.

After reading this post you will:

• Learn about some basic Kratix concepts
• Learn how to write a Compound Promise
  • By transforming an user's request into a series of sub-requests
  • By sending those sub-requests to the Platform cluster (and why you need it)
  • By defining the sub-Promises that the parent Promise depends on

Click on "read more" to continue!

Ever wondered how Kratix actually gets your documents from the Platform Cluster to the correct Destination?

The Syntasso Team has recently introduced a change to Kratix to reduce the size of the Work object. While this change is mostly internal, we wanted to share how the innards of Kratix work.

So brace yourself to learn:

• how Kratix moves documents from Platform to Destinations
• what works and workplacements are
• how to inspect works to debug your Promises

You are probably already familiar with how Kratix works at a high level and with the diagram below:

As illustrated above:

1. The user sends a new App Request to the Platform Cluster.
2. The Promise reacts to that request and triggers the Resource Configure Workflows.
3. The Workflow completes and outputs a series of documents to be scheduled to a Destination.
4. These documents are written to a specific directory in the State Store.
5. In the diagram, the documents are scheduled to a Kubernetes Destination. These type of Destination usually have Flux (or ArgoCD, or another GitOps tool) watching the State Store. The tool picks up the new documents.
6. The documents are then processed and applied to the Destination.
7. The App becomes operational on the Destination.

In this post, I'm going to expand on points (3) and (4): what happens at the end of the Workflow? How is the document written to the State Store? And how does the change linked above affect this process?

Hi friends 😊 I'm Cat, Product Manager here at Syntasso, and I've been listening to you, our avid followers. "Cat, we love Kratix, and we love your team; we want an update!" I hear you scream, so here I am, delivering this top-quality content. You're welcome.

Given that this is our first Kratix Product Update™ (not really ™), I wanted to shout about some of the great work the team has done over the last few months, so we're going back a bit further than we usually will… Indulge me; it was my birthday this month.

TL;DR​

If you only have 10 seconds spare to read this blog, these are the features you need to know about:

• We have two CLIs now! One for building promises and one for installing SKE (Syntasso Kratix Enterprise)
• Setting permissions just got a little bit easier
• If you like Backstage, you’ll like what we’re up to