-
(end-of-month releases only) Update Bicep Az types:
- Run the Update Types GitHub Action to generate the latest type definitions.
- Wait ~3hrs for it to complete. Ensure it runs successfully.
- Submit a PR to merge the
autogenerate
branch tomain
. You can use this link to start the PR.
- Run the Official Build for BicepMirror-Types-Az(see this README for instructions). Note: There are several (non-blocking) known issues:
- Publish Bicep.Types.Az NuGet packages to nuget.org. Follow the latter half of the readme here and the below steps.
- Find your build here and wait for it to finish successfully. Then click on it and for the
drop_build_main
, download the artifacts. - Follow instructions to download the nuget.exe from here
- Run
./scripts/UploadPackages.ps1 -PackageDirectory <downloads>/drop_build_main -NuGetPath <nuget_tool_directory>
- You need to be part of the armdeployments org on nuget.org. (Ask one of the admins to be added) You must generate an API key and then use that as the password for when the popup window appears after running the above command. (Username can be anything)
- Find your build here and wait for it to finish successfully. Then click on it and for the
- Bump the Bicep.Types.Az NuGet package version in this project in this file by creating and merging a PR
- Might need to run a
dotnet restore
to update the packages.lock.json files - Might also need to update baseline tests (run
bicep/scripts/UpdateBaselines.ps1
)
- Might need to run a
- Run the Update Types GitHub Action to generate the latest type definitions.
-
Verify the latest build on the
main
branch is green: Build on main. -
Review history for changes to bicepconfig.schema.json. Create a GitHub issue for it if none already exists and notify the team for any recently-added linter rules which do not have public documentation. This is non-blocking for the release process (continue to the next step).
-
(end-of-month releases only) Bump the version number by incrementing the minor version number in this file (example here)
-
Run the Official Build for BicepMirror (see this README for instructions).
-
Push the version tag for the commit used to generate the official build.
- Obtain the version number from official build. This should be of format
vXX.YY.ZZ
- e.gv0.14.85
.- Look at either the official build artifacts or
- Look at random logs of the the build from here. One example might be bicep_windows -> Copy Bicep registry module tool package to output (windows_build_container)
- In the Bicep repo, run
git tag v<new_release_number> <commit_hash>
, where<commit_hash>
is the git commit hash used for the official build (ex:git tag v0.15.31 3ba6e06a8d412febd182e607d0f5fe607ec90274
). - Run
git push origin v<new_release_number>
to push the tag (ex:git push origin v0.15.31
).
- Obtain the version number from official build. This should be of format
-
Create a draft release for the new tag and set release title to the tag name. Use the "Save draft" button to save the changes without publishing it.
-
Run
bicep/scripts/CreateReleaseNotes -FromTag <previous tag> -ToTag <new tag>
and set the output as the release description.- Give the output of this script to a PM, and ask them to clean up the notes for the release.
- Once they have cleaned up the notes, copy + paste them into the draft notes, and hit "Save draft" again.
-
Run
BicepMirror/scripts/UploadSignedReleaseArtifacts.ps1
to add official artifacts to the release.-WorkingDir
can be any empty temporary directory that you create-BuildId
is only needed if the latest official build is NOT the official build you are trying to release
-
Validate VSCode extension and Bicep CLI manually on Windows, Mac & Linux:
- Download
vscode-bicep.vsix
from the draft release, and Install it from VSIX. Verify that you can open a Bicep file, that text is correctly colorized, and that error messages show up as expected. - Download the appropriate Bicep executable for your platform (e.g.
bicep-linux-x64
). Verify you can invoke it with e.g.bicep-linux-x64 --version
, and that it prints the expected output.
- Download
-
Verify that the draft release on GitHub has at least 28 artifacts associated with it before publishing it. (On the Bicep releases page it should state that many assets. On the edit page of the draft release itself, there will be two fewer assets because the 2 source code files don't show up.)
-
Publish the release on GitHub.
-
Upload copyleft dependency source to 3rd party disclosure site. See instructions.
-
Upload vscode-bicep.VSIX to the VS marketplace here. You may need access permissions, request help in the team channel.
- Click on the ... for Bicep, then Update, then upload the .vsix file. The site will verify it then the version number should be updated to the right one.
-
Upload vs-bicep.VSIX to VS marketplace
- Click on the ... for Bicep for Visual Studio, then Edit.
- Copy/paste the text from the current version of src\vs-bicep\README.md over the existing text in the "Overview" field (this can only be changed on the marketplace when publishing a new version)
- Upload the new vs-bicep.VSIX file at the top. This should update the Version number automatically for you. Verify that it does.
- Scroll to the bottom and hit Save and Upload.
-
Upload NuGet packages to nuget.org via
BicepMirror/scripts/PublishPackages.ps1
. This is an almost identical process to publishing the BicepMirror-Types-Az nuget packages so look at that previous step above. (Make sure to include CLI packages.) This can be done one of two ways:- Easiest is to use the
__assets
directory created by theUploadSignedReleaseArtifacts.ps1
script. - You can also download all the files from the published release into a separate folder and run the script using that folder. (The script looks for files ending in *.nupkg)
- Easiest is to use the
-
Update homebrew by going here here and clicking on
Run workflow
-
[PM Task] Post a twitter/X thread on BicepLang twitter account, which the following individual tweets/posts:
- Highlights from Release Notes with link to full release
- Link to the most recent community call
- Links to any relevant new docs