Is it possible to not use JSON parameters file and instead just a deployable test/main.test.bicep in the current CI setup?

[BenjaminEngeset]

Is it possible to not use JSON parameters file and instead just a deployable test/main.test.bicep in the current CI setup?

Have not checked in detail, but it would be very interesting if this is possible, or atleast some tweaking to achieve it.

[AlexanderSehr]

Hey @bengeset96 , it is and we are currently investigating this. You can see examples of how this can be done for example here in the AvailabilitySet module we contributed to the Public Bicep Registry.

Further, as an intermediate step, we have the PR #1362 that will provide automatically converted versions of the parameter files in both Bicep & ARM in the Module's ReadMe file.

There a different pro's and con's to either approach - hence the ReadMe PR gives examples for both.

[BenjaminEngeset]

Great @MrMCake. Really looking forward to that! Have been using the same approach as CARML for our ADO repository, but would really like to see support for main.test.bicep instead rather than having to deal with JSON at all.

It would also be really nice to see support for one .yml on pull request that actually deploys the module, rather than manually have to define it in .yml context and run it beforehand with segregated .yml per module.

It is possible to add each pipeline as branch policy, but it will not be scalable in the long run when working with big repos.

I know this is not a directly easy task to solve. Bicep Public Registry CI has this, but only supports RG level deployments for now.

[AlexanderSehr]

Love it @bengeset96, a few thoughts my my side:

• main.test.bicep
  • As you pointed out, this is used by the Public Bicep Registry. The advantage is, that the deployment time is kept at a minimum
  • However, at the same time that means that all deployments fails as soon as one of the test deployments fail. In case of our VM module for example we have 4 test deployments which makes troubleshooting significantly harder if one, or two of them fail. Whether we use one main.test.bicep file, or multiple + 1 file for the dependencies will eventually be a judgement call
• Module pipelines
  • That's I guess the dream. If we'd only have one pipeline instead of 90 it is definitely a win. The primary reasons why we currently have one pipeline per module are: The ability to trigger a pipeline for a specific module & the different triggers (that are module specific)
  • However, it should be something we strive for once we figure out a good implementation to make it a reality without compromising functionality

[BenjaminEngeset]

Agreed. CI for infrastructure as code is not easy when it should be so extremely flexible and support "all" cases.

[rahalan]

blocked: new dependency approach needs to be in place

[AlexanderSehr]

Foundation will be implemented with PR #1624, followed by an effort to transform all JSON-Parameter Files into Bicep-Test-Files.

[AlexanderSehr]

Will close as it is already on the roadmap (to avoid duplicates - #1583)