Our great sponsors
-
ResourceModules
This repository includes a CI platform for and collection of mature and curated Bicep modules. The platform supports both ARM and Bicep and can be leveraged using GitHub actions as well as Azure DevOps pipelines.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
As for the actual usage of Private Registry, we have two separate Azure DevOps pipelines; one for pull requests, that generates a simple markdown doc for the parametrs and runs psrule scan on the module(s). Another pipeline then pushes the modules to the private registry with az bicep publish.
For Pull Requests, it compiles bicep into ARM templates and runs PSDocs for them an accompaying json file that holds versioning information and, document title and some additional information. Then it looks for ./test/module.test.bicep -file (which is just a copy of a suitable test suite from ResourceModules) and runs psrule against that. For runs triggered from main-branch, it queues the module publishing pipeline for every changed module.bicep found.
Currently the automated testing we have in the pipeline is only building the bicep into ARM, and running psrule against the biceps (which, I think, is essentially the same thing). We used to run the Test-command of PSBicep-module (https://github.com/PSBicep/PSBicep/blob/main/Docs/Help/Test-BicepFile.md), but ran into problems with that one, as the module tends to lack behind latest bicep features a bit - same thing with a lot of tooling like psrule.
We have a separate parameter file for every landing zone instance (our implementation is a bare-bones CAF landing zone, kinda like https://github.com/Azure/bicep-registry-modules/tree/main/modules/lz/sub-vending, which is avaible from bicep public registry), where instance is for example a separate environment (dev/test/prod). This parameter file only represents the configuration, so things like subnets, nsgs and so on, and it has nothing to do with the landing zone implementation as such.