We should be able to define some simple unit tests which verify that patches that are installed in the images correspond to the KB numbers listed in the manifest.versions.json file. This ensures that the Dockerfiles have been generated correctly from that metadata.
This is particularly useful due to the patching strategy of 4.8 runtime Dockerfiles. We keep the 4.8 runtime Dockerfiles updated with the latest patch even if it's not security-related. But when there is a security patch for 4.8, we need to configure the 4.8-is-security-release variable to true. This causes the generated Dockerfiles to not install the patch. They don't need to install the patch because it'll already be installed by the base Windows image. However, consider that the next release following the security patch is a non-security release. In that case, we must set the variable back to false to ensure that the patch gets applied by the Dockerfile. If switching it back to false was mistakenly forgotten, a unit test which verified that the patch is installed in the image would catch this.
Another variant of this type of test would be to verify the 4.8-is-security-release variable is correctly set to true. Not setting it to true when it should would cause unnecessary installation of a patch that already exists in the base Windows image, leading to layer bloat in the image. To guard against this, a test could read the KB number from the manifest.versions.json file and compare it to the patches installed in the base Windows image. If the patch exists in the base Windows image, then 4.8-is-security-release should be set to true.
For implementation purposes, the way to check which patches are installed is the following PowerShell command: Get-HotFix.
We should be able to define some simple unit tests which verify that patches that are installed in the images correspond to the KB numbers listed in the manifest.versions.json file. This ensures that the Dockerfiles have been generated correctly from that metadata.
This is particularly useful due to the patching strategy of 4.8 runtime Dockerfiles. We keep the 4.8 runtime Dockerfiles updated with the latest patch even if it's not security-related. But when there is a security patch for 4.8, we need to configure the
4.8-is-security-releasevariable totrue. This causes the generated Dockerfiles to not install the patch. They don't need to install the patch because it'll already be installed by the base Windows image. However, consider that the next release following the security patch is a non-security release. In that case, we must set the variable back tofalseto ensure that the patch gets applied by the Dockerfile. If switching it back tofalsewas mistakenly forgotten, a unit test which verified that the patch is installed in the image would catch this.Another variant of this type of test would be to verify the
4.8-is-security-releasevariable is correctly set totrue. Not setting it to true when it should would cause unnecessary installation of a patch that already exists in the base Windows image, leading to layer bloat in the image. To guard against this, a test could read the KB number from the manifest.versions.json file and compare it to the patches installed in the base Windows image. If the patch exists in the base Windows image, then4.8-is-security-releaseshould be set totrue.For implementation purposes, the way to check which patches are installed is the following PowerShell command:
Get-HotFix.