Hi 👋🏼, I am Niklas, a DevOps engineer from Cologne, Germany.

Using the GitHub API in Deno is as simple as importing the Octokit client shown in the GitHub documentation. Since Deno supports npm packages, you can easily use the Octokit client in Deno. In this short article I will show you how to use the Octokit client to get the workflow runs for a repository.

Today I want to talk about Deno and GitHub Actions. For the last year or so, I have only built new projects with Deno. I really like the runtime, it's typescript out of the box config, formatting, linting etc. It is just a lot of fun to work with.

Since I still wanted to make sure that everything works when pushed to our Github repositories, I had to build some GitHub actions. Today I want to share a repository where I collect useful actions. At the time of writing, the repository contains 3 different workflows. You can find the repository at niklasmtj/deno-actions on GitHub.

Caution: If you are using an AWS managed node group, before switching to the launch template below, AWS will delete the current node group and then create the new node group based on the template. Your pod and cluster configuration should not be deleted, but the pods will not be provisioned for the duration of the node change.

Since I didn't find the appropriate Terraform resource to start AWS EKS nodes without the AWS-defined pod limits per node, here it is. Why AWS defines limits and how to configure your Amazon VPC CNI plugin can be found in this blog post from AWS. I will show the Terraform Launch Template resource needed to start the kubelet without the pod limit defined by AWS.

This blog post will outline a way to get changes from development into production. There are many different ways to do this. This is one way, and there is not the one way from dev to production. In the following, I will talk about a way that I have experience with and like the way of the process. The process described in this post will follow the typical Software Development Lifecycle. The definition of it will also not be part of the post. However I will briefly describe what happens in the 3 phases of development, staging and production.

The previous post was about conditional jobs [^1]. GitHub also offers the possibility of providing individual steps with a condition. The usage is almost identical to the conditional jobs. How you can implement them is described below.