Release Images for Linux Dedicated (GitHub Action)

This operation requires Contributor role.

Step 1: Create a PR for updating Host Version

This pipeline will update the host version and create a Pull Request. If all images in a Major Version do not share hostVersion and extensionBundleVersions scripts in this action will fail. If the intention is to update only some of the images, these checks can be safely skipped. But, the removal of the scripts should be called out in the hotfix PR

Go to Actions tab, click Host version up and create PR.
Click Run workflow. Fill the following column.

• Branch: dev
• Major Version: (e.g. 3)
• Target Version: (e.g. 3.1.1)

Click Run workflow

Step 2: Review and merge PR

Review and merge the PR that is created by this pipeline.

Note: It is important to merge the PR before proceeding to the next step

Step 3: Release tag

This pipeline will merge dev into a branch then tag with the host version. then create a release.

Go to Actions tab, click Release.

Click Run workflow. Fill the following column.

• Branch: dev
• Release Version: (e.g. 3.1.1)
• TargetBranch to tag: (e.g. release/3.x)

Click Run workflow.

After the pipeline has been finished, go to the Release You will find Draft Release Not is created. click Edit and review it. If you are ok, click publish.

Auto labeling

When you create a Pull Request with label, it classified automatically on the release. For the supported labels,Please refer to the configuration

Step 4: Check if the build is completed in the following pipeline:

For each of the builds below, check for a successful build triggered on the version tag you are releasing. e.g.

• v3 python build
• v3 node build
• v3 java build
• v3 powershell build
• v3 dotnet build
• v2 upgrade python build
• v2 upgrade node build
• v2 upgrade dotnet build

Step 5: Publish images to MCR

After the build completes, then run v3 publish pipeline.

• Set Branch/tag to "refs/tags/"

• Leave Commit blank

• Under Variables set PrivateVersion to ""

• Under Variables set TargetVersion to ""

• In our case, for pipeline v3 publish:

  • Branch/tag: refs/tags/3.a.b
  • PrivateVersion: 3.a.b
  • TargetVersion: 3.a.b

Step 6: Validation

Once the publishing completes, validate that the image versions are available in the public container registry (MCR)

• Dotnet MCR
• Dotnet-Isolated MCR
• Node MCR
• Python MCR
• Java MCR
• Powershell MCR

Step 7: Rollout to production

In this step, we publish the version being released (e.g. 3.a.b) to the public image tag (e.g. 3.0).

• Publish pipeline v3

Step 8: Release validation/monitoring

Use this Kusto dashboard to monitor the health of Function apps as they start running on the version you released above. Follow the instructions below to get familiar with it.

Set the appropriate time range, stage, previous and current versions you are comparing:

Optional filters:

• Exception prefix: This allows you to specify a prefix to filter the results of the crashes and exception tables by. Find an exception prefix from the table of counts that you want to drill into and type it out here. Note that this is a prefix and not a substring filter.
• App Name: Filters results for just this app in the crashes and exceptions tables. Find an app from the "Top 10 … Apps" table.
• Percentile: Change the percentile used in relevant summary tables (Exceptions per App - Percentile)
• Exception prefix length: This controls the width of the prefix that the Exception messages will be truncated to for summarization of counts. The narrower the width the fewer the buckets.
• Exceptions to show: Allows you to show more or less results in the drill down table that all exceptions ordered by time.

If not clear, review the Kusto queries to get familiar with what each table means. You are looking for significant relative differences between the new version you released and the older version.