Open Gordonby opened 2 years ago
Hey @Gordonby, to elaborate: Do you mean like a function to run and publish all modules in a release to the ACR - bypassing the tests?
Not sure exactly what you mean by bypassing the tests.
I'm talking about writing a script that will take a release, iterate over the bicep files and add them to a specified Azure Container Registry using the same version tag from the release.
The complexities will be in the paths when modules refer to other modules I think.
The problem this solves is that it isn't exactly easy to consume (and keep updated) the vendored modules from this repo.
Have an idea to achieve this. A script that goes over all version.json
files and update their version for a given release. i.e. we release 0.5.0 -> bump all version files to contain 0.5
=> when pulling that in in a forked or synced repo, it will trigger a full run of all pipelines, republishing all modules.
That sounds overcomplicated.
If someone downloads the release of the bicep files, they're not necessarily storing them in GitHub or AzDo and running pipelines.
The scenario is that they just want them added to a bicep registry (Azure Container Registry).
If there's already actions/pipelines for adding the bicep files to an ACR then that sounds like it will contain much of the logic. Is that the case?
Ah, understood. Bypassing the entire CI framework in that case. Sounds like:
. '.\utilities\pipelines\resourcePublish\Publish-ModuleToPrivateBicepRegistry.ps1'
$ModuleVersion = '1.0.0' $BicepRegistryName = 'mybicepregistry123' $BicepRegistryRgName = 'artifacts-rg'
Get-ChildItem -Path .\arm\ -Filter deploy.bicep -Recurse | ForEach-Object { Publish-ModuleToPrivateBicepRegistry -TemplateFilePath $_.FullPath -ModuleVersion $ModuleVersion -BicepRegistryName $BicepRegistryName -BicepRegistryRgName }
NOTE: Code snippet is not tested :D
Perhaps there's some terminology at play here, but if I'm downloading a release from this repo - I'd say that it's tested 😄
I'm looking in the wiki, and I can see Option 1 would be the preferred route, (it does refer to the testing that has been mentioned a few times in the comments) but this option doesn't fit everyone.
Option 2 is the more traditional vendoring of releases (which is what i'm talking about). However a cloned repo is not particularly consumable from other repos where people would be writing their bicep files. It makes sense to me to extend Option 2 to include the script you've mentioned above, which can be run manually each time a release of the ResourceModules is taken.
Here's a working version of the code snippet provided
#create acr
$acrname="carml"
$rg="innerloop"
az acr create -n $acrname -g $rg --sku standard
#download release
$repoApiUrl="https://api.github.com/repos/Azure/ResourceModules/releases/latest"
$latestRelease=Invoke-RestMethod -Uri $repoApiUrl
$moduleVersion=$latestRelease.tag_name
$zipPath="carml-$moduleVersion.zip"
Invoke-WebRequest -Uri $latestRelease.zipball_url -MaximumRedirection 5 -OutFile $zipPath
#unzip release and cd
Expand-Archive -Path $zipPath -DestinationPath .\carmlReleases\$moduleVersion
cd .\carmlReleases\$moduleVersion\Azure-ResourceModules-cfcb9d5
#Add publish function to runspace
. .\utilities\pipelines\resourcePublish\Publish-ModuleToPrivateBicepRegistry.ps1
#Add files to ACR
$bicepFilesToPublish = Get-ChildItem -Path .\arm\ -Filter deploy.bicep -Recurse
write-output "$($bicepFilesToPublish.count) bicep files to publish to ACR $acrname in $rg"
$bicepFilesToPublish | ForEach-Object {
Write-Output "Processing $($_.VersionInfo.FileName)"
Publish-ModuleToPrivateBicepRegistry -TemplateFilePath $_.VersionInfo.FileName -ModuleVersion $moduleversion -BicepRegistryName $acrname -BicepRegistryRgName $rg
}
Description
Feature idea. A documented method for populating a private Azure Container Registry with all of the bicep modules in a particular release.