Azure
Support manually setting contentVersion
Would definitely be handy as we use this to detect if resources need to be deployed in the pipeline so we aren't wasting cycles on waiting for changes when no changes are needed.
Our team is also very much interested in this feature, as we need to fall back to using another template based on the content version.
Out of curiosity, have you considered using a bicep registry (which supports versions) instead of using the contentVersion property?
@alex-frankel what good would that do? The contentVersion shows up in the deployment, but the tag from the bicep registry shows up only in my source code, and is never even available to be logged by bicep.
@alex-frankel - I've just come across a use case for setting ContentVersion too as part of an effort to progress from an ARM deployment system to include Bicep.
ContentVersion is leveraged in post build steps in the existing ARM system.
ContentVersion is described in the ARM docs as;
Version of the template (such as 1.0.0.0). You can provide any value for this element. Use this value to document significant changes in your template. When deploying resources using the template, this value can be used to make sure that the right template is being used.
We really should have a way to set it, either from within the bicep file or as an argument to the bicep build command.
Just revisiting this issue again. Quite a smaller and likely under utilised feature of ARM - but would still be good to support even from a basic perspective in bicep.
I think this is an interesting idea, but I also feel like the contentVersion field as of today isn't flexible enough to support other interesting use cases - for example, I think it would be really useful to embed metadata such as "source commit" or "source repo"
{
"parameters": {},
"languageVersion": "2.0",
"resources": {},
"metadata": {
"_generator": {
"name": "bicep",
"version": "0.22.6.54827",
"templateHash": "4713413752423414014"
},
"_source": {
// this would give enough information for an editor to link to an exact point-in-time copy of the original source file - e.g.
// https://github.com/Azure/bicep-registry-modules/blob/02050197700fb3abe82deb91e487898a1f92a0f1/modules/azure-gaming/game-dev-vm/main.bicep
"repositoryUrl": "https://github.com/Azure/bicep-registry-modules",
"ref": "02050197700fb3abe82deb91e487898a1f92a0f1",
"filePath": "modules/azure-gaming/game-dev-vm/main.bicep"
}
}
}
This could light up some interesting scenarios similar to SourceLink
