Techtips

When you’re creating scripts, in some cases, you may want to limit what values a consumer is allowed to provide for a specific parameter. In PowerShell a regular way to do that is with ValidateSet. ValidateSet is an attribute that you can define on a parameter together with a set of values that are allowed to be provided for the parameter. For example, let’s say you want to only allow to specify Development, Staging or Production as a value for the $DeploymentEnvironment parameter in your PowerShell script, with help of ValidateSet. It can look something like this: ...

In this edition of Tech Bits and Bobs I would like to give a quick overview of how to reference variables and secrets, that are defined in the repository variables and secrets and in a GitHub Deployment Environment, in a reusable GitHub workflow. Disclaimer: there’s a tiny nuance to be aware of when it comes to referencing secrets 😼 The good thing is that you can reference all the variables and secrets that are coming both from the repository secrets and variables and the deployment environments in a regular way, i.e. ${{ secrets.MY_SECRET_FROM_ANYWHERE }} or ${{ vars.MY_VAR_FROM_ANYWHERE }}. The only caveat here is that when you want to reference secrets in a reusable workflow, be it from the repo or a deployment environment, you need to provide secrets: inherit parameter in the parent workflow job that is calling upon a reusable workflow. This parameter allows reusable workflow to access the secrets that the parent workflow has access to. ...

I was recently working on automating some manual actions related to my tech blog and discovered an interesting use case that I thought was worth sharing with the community 😊 Did you know that it is possible to trigger a GitHub workflow that resides in a different repository? Let me show you how!😼 There are multiple approaches to how you can implement this but I have found following approach to be most preferrable. Let’s say that you have repository A and repository B, and you want to trigger a GitHub workflow in repository B once workflow in repository A succeeds. ...

Recently a new property became available in Azure Portal when creating a new Azure Kubernetes Service instance: Have you seen it and do you know what it actually is? Wait, does AKS have pricing tiers?! I thought that the only price we need to pay was based on the chosen VM SKU for AKS Nodes….right?🤨 Well, the answer is yes and no.😺 By default AKS is a free service and you only pay for the virtual machines you choose for your Nodes, plus associated storage and networking resources. There are nevertheless some additional billed capabilities that can be enabled, like Uptime SLA, which is now more streamlined with visibility in Azure Portal. ...

A thought struck me one day when I was working with onboarding machines to Azure Arc. If you want to onboard multiple servers at scale to Azure Arc, you would need a Service Principal with Azure Connected Machine Onboarding role in the respective subscription or resource group where you want to create Azure Arc-enabled servers. An interesting thing here is: what if you would like to re-use the same service principal in order to onboard more Azure Arc resources but to another subscription and/or another resource group? ...