Skip to content

Latest commit

 

History

History
60 lines (57 loc) · 7.97 KB

release-checklist.md

File metadata and controls

60 lines (57 loc) · 7.97 KB
Raw

Bicep Release Checklist

  1. (end-of-month releases only) Update Bicep Az types:

    1. Run the Update Types GitHub Action to generate the latest type definitions.
      1. Wait ~3hrs for it to complete. Ensure it runs successfully.
      2. Submit a PR to merge the autogenerate branch to main. You can use this link to start the PR.
    2. Run the Official Build for BicepMirror-Types-Az(see this README for instructions). Note: There are several (non-blocking) known issues:
    3. Publish Bicep.Types.Az NuGet packages to nuget.org. Follow the latter half of the readme here and the below steps.
      1. Find your build here and wait for it to finish successfully. Then click on it and for the drop_build_main, download the artifacts.
      2. Follow instructions to download the nuget.exe from here
      3. Run ./scripts/UploadPackages.ps1 -PackageDirectory <downloads>/drop_build_main -NuGetPath <nuget_tool_directory>
      4. 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)
    4. Bump the Bicep.Types.Az NuGet package version in this project in this file by creating and merging a PR
      1. Might need to run a dotnet restore to update the packages.lock.json files
      2. Might also need to update baseline tests (run bicep/scripts/UpdateBaselines.ps1)

  2. Verify the latest build on the main branch is green: Build on main.

  3. 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).

  4. (end-of-month releases only) Bump the version number by incrementing the minor version number in this file (example here)

  5. Run the Official Build for BicepMirror (see this README for instructions).

  6. Push the version tag for the commit used to generate the official build.

    1. Obtain the version number from official build. This should be of format vXX.YY.ZZ - e.g v0.14.85.
      1. Look at either the official build artifacts or
      2. 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)
    2. 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).
    3. Run git push origin v<new_release_number> to push the tag (ex: git push origin v0.15.31).

  7. 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.

  8. Run bicep/scripts/CreateReleaseNotes -FromTag <previous tag> -ToTag <new tag> and set the output as the release description.

    1. Give the output of this script to a PM, and ask them to clean up the notes for the release.
    2. Once they have cleaned up the notes, copy + paste them into the draft notes, and hit "Save draft" again.

  9. 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

  10. Validate VSCode extension and Bicep CLI manually on Windows, Mac & Linux:

    1. 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.
    2. 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.

  11. 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.)

  12. Publish the release on GitHub.

  13. Upload copyleft dependency source to 3rd party disclosure site. See instructions.

  14. Upload vscode-bicep.VSIX to the VS marketplace here. You may need access permissions, request help in the team channel.

    1. 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.

  15. Upload vs-bicep.VSIX to VS marketplace

    1. Click on the ... for Bicep for Visual Studio, then Edit.
    2. 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)
    3. Upload the new vs-bicep.VSIX file at the top. This should update the Version number automatically for you. Verify that it does.
    4. Scroll to the bottom and hit Save and Upload.

  16. 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:

    1. Easiest is to use the __assets directory created by the UploadSignedReleaseArtifacts.ps1 script.
    2. 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)

  17. Update homebrew by going here here and clicking on Run workflow

    • A PR will be auto created by this action (example here). Approve and merge it.
    • The above about PR auto creation is not true anymore. The workflow will create the branch and add a commit, but you have to manually create a PR by going to the branch. Get the PR approved then merge it.

  18. [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