When writing advanced functions in PowerShell, ShouldProcess enables a script to ask for confirmation and react to different settings of $ConfirmPreference. Unfortunately, the use of ShouldProcess is still somewhat obsure. Therefore, I have created template for this and added unit tests to proove it works correctly.
Once in a while you will decide to execute tasks in parallel to speed up the whole process. And you will quickly start exploring PowerShell jobs. Although they are easy to start off, they always spawn a new empty instance of PowerShell. This post provides an example how to work around this.
When using the USER directive in Dockerfile, all subsequent commands are forced to run as the specified user. This is a security feature to prevent processes from changing the configuration inside the container. But this is a nightmare when troubleshooting because you cannot make changes to the container trying to fix the issue at hand. Luckily, there is a way around this security feature when running containers on Windows.
Many of your may already be using pester to write unit tests for PowerShell functions. By default, pester only shows which tests have succeeded and which have failed. Fortunately, pester can also analyze the code coverage} of those tests - meaning it can tell you how much of your code was actually tested. In this post I will show you how to determine line and function coverage for your tests.
I am proud to announce that our third book about Hyper-V is now available. For this new edition we have taken the time to update most of the book with new information about Windows Server 2016. We have also added a new chapter about containerization using Docker.
I am proud to announce that Docker honours my community contributions by including me in the Docker Captains Program.
In an earlier post, I demonstrated how to use PowerShell Desired State Configuration (PSDSC) in containers. But I did not state clearly enough that PSDSC should be used in image builds but not during the runtime of a container. Let’s take a closer look why this makes sense.
When working with PowerShell, you often come across data you need to analyze. The usual way it to export the values to a CSV file, import it to a spreadsheet and create some charts. Although you end up with a nice graphical representation of your data, it usually suffices to understand quickly you data to decide how to proceed. With my statistics PowerShell module, data analysis is performed right on the console. Display histograms from the pipeline.
When you are working with Docker and you are planning to test something quickly on your workstation… but you are behind a proxy. You fail to pull an image. You fail to build an image. You fail to download from the image. But not anymore after reading this post.
When using Windows containers on Windows 10, you sometimes end up behind a proxy server. Unfortunately, the Docker service does not use the proxy server configured for Windows itself. Instead, it uses the environment variables commonly used on Linux.
[Environment]::SetEnvironmentVariable(“HTTP_PROXY”, “http://1.2.3.4:3128”, [EnvironmentVariableTarget]::Machine) [Environment]::SetEnvironmentVariable(“HTTPS_PROXY”, “http://1.2.3.4:3128”, [EnvironmentVariableTarget]::Machine)