So a consequence of wanting to purge images from your container registry is sometimes you need to keep some of them.
One example is that in regulated industries you must be able to produce software that was deployed to production for audit/legal purposes, so if you are purging images that are over 3 months old you might have an issue.
You can update an image so that it can’t be overridden or deleted via the az acr repository update command e.
One housekeeping task if you are producing docker images is clearing your container registry of old images.
I’ve been particularly bad at this and had also made some mistakes such as publishing PR images and images produced via our auto-patching runs, leading to the ACR size being >1.2Tb (ouch!).
There are some features introduced by acr auto purge, but I found an issue since my images typically have three tags…
Just pushed a new version of WikiExport with a couple of useful features
Change titleFormat to have explicit {project}/{title} macros Support for .attachments in non-root folder - provided by @ricfre The first is just a simplification since it’s more intentional to use named values rather than {0} etc, and we can also automatically determine projectInTitle from the titleFormat.
The second one allows support for code wikis and the image path not being in the root of the repository e.
One perennial issue when developing software is how to keep documentation up to date. For detailed documentation such as APIs this has become a lot easier in recent years with capabilities such as Swashbuckle being able to pick up annotations directly from the code.
The principal of keeping your documentation as close to the code as possible means that development teams are more likely to keep it up to date and relevant to the actual behaviour - presuming you are have a good definition of done and are performing code reviews 😉.
I’ve just started blogging again and decided to adopt MiniBlog, a minimal modern blog engine written by Mads Kristensen who also wrote BlogEngine.NET, as SubText has died.
It only has a small set of features and Mads intends to keep it like this, the concept is that you make your own fork on GitHub, adding the features you want and publish from there; this has a few consequences…
Your blog credentials are visible in your GitHub fork Potentially your content is there as well How to test out new features written by yourself and/or from other forks.
