Write every README note as a GitHub alert

README.md

@@ -97,7 +97,7 @@ container images Microsoft publishes for `amd64` alone, so there is no `arm64` i
 
 **"emulated" means `amd64` emulation, and how well the samples run depends on the emulator.** The emulator never pins `--platform`, so on an `arm64` host Docker pulls the `amd64` image and runs it under whatever emulation the runtime provides. Where none is registered, such as GitHub's `ubuntu-*-arm` runners, the image cannot start at all, which is why CI schedules only the natively-supported samples on `arm64`.
 
-> [!NOTE]
+> [!IMPORTANT]
 > **Macs with Apple silicon: turn on Rosetta.** Docker Desktop emulates `amd64` with Rosetta only when **Use Rosetta for x86_64/amd64 emulation on Apple Silicon** is on (Settings, **General**, with the **Apple Virtualization framework** as the Virtual Machine Manager; Docker VMM has no Rosetta), and with QEMU otherwise.
 > Every code deployment, Function Apps included, is built with Microsoft's Oryx build image, which is `amd64`-only ([microsoft/Oryx#2133](https://github.com/microsoft/Oryx/issues/2133) asks for `arm64`) and is a .NET app, and [.NET does not support QEMU](https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md): under QEMU that build can crash ([#143](https://github.com/localstack/localstack-azure-samples/issues/143)).
 > Microsoft [does not test or support SQL Server under emulation](https://learn.microsoft.com/azure/azure-sql/database/local-dev-experience-dev-containers) either.
@@ -108,7 +108,8 @@ them instead. The authoritative list lives in `ARM64_SAMPLE_DIRS` in [run-sample
 the CI matrix is generated from it, so adding a sample there is all that is needed to have it
 covered natively on both architectures.
 
-> **Note:** Function Apps on `arm64` were fixed by
+> [!CAUTION]
+> Function Apps on `arm64` were fixed by
 > [localstack-pro#8102](https://github.com/localstack/localstack-pro/pull/8102) and work on the
 > current `localstack/localstack-azure:latest`. If you pin an older emulator image, expect every
 > Function App deployment to fail with a misleading `500 ... No route to host`: those images

samples/aci-blob-storage/python/terraform/README.md

@@ -23,7 +23,8 @@ The [deploy.sh](deploy.sh) script first builds and pushes the Docker image to a
 1. [Azure Storage Account](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-overview): Provides blob storage for vacation activity data.
 2. [Azure Container Instances](https://learn.microsoft.com/en-us/azure/container-instances/container-instances-overview): Runs the containerized Flask application with public IP and DNS label.
 
-> **Note:** Key Vault is not included in the Terraform deployment as the Azure Terraform provider does not yet support LocalStack's Key Vault URI format. The storage connection string is passed directly to ACI as a secure environment variable.
+> [!NOTE]
+> Key Vault is not included in the Terraform deployment as the Azure Terraform provider does not yet support LocalStack's Key Vault URI format. The storage connection string is passed directly to ACI as a secure environment variable.
 
 For more information on the sample application, see [ACI Blob Storage](../README.md).
 

samples/api-management-function-app/python/README.md

@@ -58,7 +58,7 @@ The life of a request: the client calls `GET /inventory/items` on the gateway wi
 - [Bicep](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/install) (for the Bicep deployment)
 - A LocalStack account with a valid `LOCALSTACK_AUTH_TOKEN` (see the [Auth Token guide](https://docs.localstack.cloud/getting-started/auth-token/))
 
-> [!NOTE]
+> [!IMPORTANT]
 > **Macs with Apple silicon**: the function app runs natively on arm64, but the emulator builds each deployment with Microsoft's Oryx build image, which Microsoft publishes for amd64 only ([microsoft/Oryx#2133](https://github.com/microsoft/Oryx/issues/2133) asks for arm64).
 > Docker Desktop runs that build under amd64 emulation: in Docker Desktop's settings, under **General**, select the **Apple Virtualization framework** as the Virtual Machine Manager and turn on **Use Rosetta for x86_64/amd64 emulation on Apple Silicon**.
 > Under QEMU, which Docker Desktop uses otherwise (Rosetta off, or Docker VMM, which has no Rosetta), the build can crash, because Oryx is a .NET app and [.NET does not support QEMU](https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md).

samples/eventhubs-eventgrid/python/README.md

@@ -93,13 +93,14 @@ whatever happened to be in the last batch.
 - Python 3.12+ with `src/producers/requirements.txt` installed.
 - `jq` and `zip`.
 
+> [!IMPORTANT]
 > **The emulator must be able to resolve `cdn.functions.azure.com` from the function container.**
 > The Event Hubs trigger lives in the Functions extension bundle, which the host downloads on
 > every cold container. If the emulator's DNS server cannot forward external queries, the host
 > aborts and the trigger silently never fires. Starting the emulator with `DNS_ADDRESS=0`
 > sidesteps it.
 
-> [!NOTE]
+> [!IMPORTANT]
 > **Macs with Apple silicon**: the function app runs natively on arm64, but the emulator builds each deployment with Microsoft's Oryx build image, which Microsoft publishes for amd64 only ([microsoft/Oryx#2133](https://github.com/microsoft/Oryx/issues/2133) asks for arm64).
 > Docker Desktop runs that build under amd64 emulation: in Docker Desktop's settings, under **General**, select the **Apple Virtualization framework** as the Virtual Machine Manager and turn on **Use Rosetta for x86_64/amd64 emulation on Apple Silicon**.
 > Under QEMU, which Docker Desktop uses otherwise (Rosetta off, or Docker VMM, which has no Rosetta), the build can crash, because Oryx is a .NET app and [.NET does not support QEMU](https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md).

samples/eventhubs/python/README.md

@@ -104,7 +104,7 @@ schema registry.
 - [Terraform](https://developer.hashicorp.com/terraform/downloads) or the Bicep CLI, for
   the alternative deployments
 
-> [!NOTE]
+> [!IMPORTANT]
 > **Macs with Apple silicon**: this sample's dashboard is a web app deployed from code. The emulator builds it with Microsoft's Oryx build image and runs it on an Oryx runtime image, and Microsoft publishes both for amd64 only ([microsoft/Oryx#2133](https://github.com/microsoft/Oryx/issues/2133) asks for arm64).
 > On a Mac with Apple silicon they run only under Docker Desktop's amd64 emulation: in Docker Desktop's settings, under **General**, select the **Apple Virtualization framework** as the Virtual Machine Manager and turn on **Use Rosetta for x86_64/amd64 emulation on Apple Silicon**.
 > Under QEMU, which Docker Desktop uses otherwise (Rosetta off, or Docker VMM, which has no Rosetta), the sample is not expected to work: Oryx is a .NET app, and [.NET does not support QEMU](https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md).
@@ -130,7 +130,7 @@ bash scripts/run-pipeline.sh  # run the end-to-end demo
 
 Then open the dashboard URL printed at the end of the deployment.
 
-> **Note**
+> [!NOTE]
 > The first deployment downloads the Azure Functions build image and core tools inside the
 > emulator, which can take several minutes. Later runs reuse them.
 

samples/function-app-front-door/python/README.md

@@ -69,7 +69,7 @@ The life of a request: the client calls `GET /catalog/1` on the endpoint → the
 - [jq](https://jqlang.org/) and `zip`
 - A LocalStack account with a valid `LOCALSTACK_AUTH_TOKEN` (see the [Auth Token guide](https://docs.localstack.cloud/getting-started/auth-token/))
 
-> [!NOTE]
+> [!IMPORTANT]
 > **Macs with Apple silicon**: the function app runs natively on arm64, but the emulator builds each deployment with Microsoft's Oryx build image, which Microsoft publishes for amd64 only ([microsoft/Oryx#2133](https://github.com/microsoft/Oryx/issues/2133) asks for arm64).
 > Docker Desktop runs that build under amd64 emulation: in Docker Desktop's settings, under **General**, select the **Apple Virtualization framework** as the Virtual Machine Manager and turn on **Use Rosetta for x86_64/amd64 emulation on Apple Silicon**.
 > Under QEMU, which Docker Desktop uses otherwise (Rosetta off, or Docker VMM, which has no Rosetta), the build can crash, because Oryx is a .NET app and [.NET does not support QEMU](https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md).

samples/function-app-managed-identity/python/README.md

@@ -50,7 +50,7 @@ The LocalStack emulator emulates the following services, which are necessary at
 - [Bicep extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-bicep), if you plan to install the sample via Bicep.
 - [Terraform](https://developer.hashicorp.com/terraform/downloads), if you plan to install the sample via Terraform.
 
-> [!NOTE]
+> [!IMPORTANT]
 > **Macs with Apple silicon**: the function app runs natively on arm64, but the emulator builds each deployment with Microsoft's Oryx build image, which Microsoft publishes for amd64 only ([microsoft/Oryx#2133](https://github.com/microsoft/Oryx/issues/2133) asks for arm64).
 > Docker Desktop runs that build under amd64 emulation: in Docker Desktop's settings, under **General**, select the **Apple Virtualization framework** as the Virtual Machine Manager and turn on **Use Rosetta for x86_64/amd64 emulation on Apple Silicon**.
 > Under QEMU, which Docker Desktop uses otherwise (Rosetta off, or Docker VMM, which has no Rosetta), the build can crash, because Oryx is a .NET app and [.NET does not support QEMU](https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md).
@@ -84,7 +84,7 @@ Deploy the application to LocalStack for Azure using one of these methods:
 
 All deployment methods have been fully tested with both user-assigned and system-assigned managed identities against Azure and the LocalStack for Azure local emulator.
 
-> **Note**  
+> [!NOTE]
 > When you deploy the application to LocalStack for Azure for the first time, the initialization process involves downloading and building Docker images. This is a one-time operation—subsequent deployments will be significantly faster. Depending on your internet connection and system resources, this initial setup may take several minutes.
 
 ## Test
@@ -232,7 +232,7 @@ You can use [Azure Storage Explorer](https://learn.microsoft.com/en-us/azure/sto
 
 ![Azure Storage Explorer](./images/azure-storage-explorer.png)
 
-> **Note**  
+> [!TIP]
 > When sending commands to an emulated storage account, make sure to use the primary key generated by the emulator itself. For convenience, if you're connecting to the storage account directly with Azure Storage Explorer, you can use the default Azurite password. For more details, see [Connect to Azurite with SDKs and tools](https://learn.microsoft.com/en-us/azure/storage/common/storage-connect-azurite).
 
 ## References

samples/function-app-managed-identity/python/bicep/README.md

@@ -60,7 +60,7 @@ param runtimeVersion = '3.13'
 
 The [deploy.sh](deploy.sh) script automates the deployment of all Azure resources and the sample application in a single step. Before running the script, customize the variable values based on your needs. In particular, use the `MANAGED_IDENTITY_TYPE` variable to specify the type of managed identity to provision: `SystemAssigned` or `UserAssigned`.
 
-> **Note**  
+> [!TIP]
 > You can use `lstk az` to proxy Azure CLI commands to the LocalStack for Azure emulator. Alternatively, run `lstk az start-interception` to automatically intercept and redirect all `az` commands to LocalStack. For more information, see the [lstk CLI documentation](https://docs.localstack.cloud/aws/developer-tools/running-localstack/lstk/).
 
 The [deploy.sh](deploy.sh) script executes the following steps:
@@ -75,7 +75,7 @@ The [deploy.sh](deploy.sh) script executes the following steps:
 - Creates zip archive in format expected by Function App
 - Uploads pre-built application package to the newly created Function App
 
-> **Note**  
+> [!TIP]
 > Azure CLI commands use `--verbose` argument to print execution details and the `--debug` flag to show low-level REST calls for debugging. For more information, see [Get started with Azure CLI](https://learn.microsoft.com/en-us/cli/azure/get-started-with-azure-cli)
 
 ## Deployment

samples/function-app-managed-identity/python/scripts/README.md

@@ -51,7 +51,7 @@ This sample provides two Bash scripts to streamline the deployment process by au
 
 These scripts eliminate manual configuration steps and enable one-command deployment of the entire infrastructure.
 
-> [!NOTE]
+> [!TIP]
 > You can use `lstk az` to proxy Azure CLI commands to the LocalStack for Azure emulator. Alternatively, run `lstk az start-interception` to automatically intercept and redirect all `az` commands to LocalStack. To revert back to the default behavior and send commands to the Azure cloud, run `lstk az stop-interception`.
 
 

samples/function-app-managed-identity/python/terraform/README.md

@@ -47,7 +47,7 @@ For more information on the sample application, see [Azure Functions App with Ma
 
 The [deploy.sh](deploy.sh) script automates the deployment of all Azure resources and the sample application in a single step. Before running the script, customize the variable values based on your needs. In particular, use the `MANAGED_IDENTITY_TYPE` variable to specify the type of managed identity to provision: `SystemAssigned` or `UserAssigned`.
 
-> **Note**  
+> [!TIP]
 > You can use `lstk az` to proxy Azure CLI commands to the LocalStack for Azure emulator. Alternatively, run `lstk az start-interception` to automatically intercept and redirect all `az` commands to LocalStack. With interception active, the standard `terraform` CLI also runs against LocalStack's Azure emulation environment, so no separate Terraform wrapper is needed. For more information, see the [lstk CLI documentation](https://docs.localstack.cloud/aws/developer-tools/running-localstack/lstk/).
 
 The [deploy.sh](deploy.sh) script executes the following steps:

samples/function-app-service-bus/dotnet/README.md

@@ -54,7 +54,7 @@ The solution is composed of the following Azure resources:
 - [Bicep extension](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-bicep), if you plan to install the sample via Bicep.
 - [Terraform](https://developer.hashicorp.com/terraform/downloads), if you plan to install the sample via Terraform.
 
-> [!NOTE]
+> [!IMPORTANT]
 > **Macs with Apple silicon**: the function app runs natively on arm64, but the emulator builds each deployment with Microsoft's Oryx build image, which Microsoft publishes for amd64 only ([microsoft/Oryx#2133](https://github.com/microsoft/Oryx/issues/2133) asks for arm64).
 > Docker Desktop runs that build under amd64 emulation: in Docker Desktop's settings, under **General**, select the **Apple Virtualization framework** as the Virtual Machine Manager and turn on **Use Rosetta for x86_64/amd64 emulation on Apple Silicon**.
 > Under QEMU, which Docker Desktop uses otherwise (Rosetta off, or Docker VMM, which has no Rosetta), the build can crash, because Oryx is a .NET app and [.NET does not support QEMU](https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md).
@@ -88,7 +88,7 @@ Deploy the application to LocalStack for Azure using one of these methods:
 
 All deployment methods have been fully tested against Azure and the LocalStack for Azure local emulator.
 
-> **Note**  
+> [!NOTE]
 > When you deploy the application to LocalStack for Azure for the first time, the initialization process involves downloading and building Docker images. This is a one-time operation—subsequent deployments will be significantly faster. Depending on your internet connection and system resources, this initial setup may take several minutes.
 
 ## Test

samples/function-app-storage-http/dotnet/METHODS.md

@@ -199,7 +199,8 @@ Automated function that generates new game rounds with random player data and in
 **Description:**  
 Template function for processing Service Bus messages. When enabled, it would process messages from a Service Bus queue and send responses to an output queue.
 
-**Note:** This function is commented out in the current implementation but serves as a reference for Service Bus integration.
+> [!NOTE]
+> This function is commented out in the current implementation but serves as a reference for Service Bus integration.
 
 ---
 

samples/function-app-storage-http/dotnet/README.md

@@ -134,7 +134,7 @@ The sample uses the following configurable settings in `local.settings.json`:
 - [jq](https://jqlang.org/) is a JSON processor for scripting.
 - [Azure Storage Explorer](https://learn.microsoft.com/en-us/azure/storage/storage-explorer/vs-azure-tools-storage-manage-with-storage-explorer) for viewing storage contents.
 
-> [!NOTE]
+> [!IMPORTANT]
 > **Macs with Apple silicon**: the function app runs natively on arm64, but the emulator builds each deployment with Microsoft's Oryx build image, which Microsoft publishes for amd64 only ([microsoft/Oryx#2133](https://github.com/microsoft/Oryx/issues/2133) asks for arm64).
 > Docker Desktop runs that build under amd64 emulation: in Docker Desktop's settings, under **General**, select the **Apple Virtualization framework** as the Virtual Machine Manager and turn on **Use Rosetta for x86_64/amd64 emulation on Apple Silicon**.
 > Under QEMU, which Docker Desktop uses otherwise (Rosetta off, or Docker VMM, which has no Rosetta), the build can crash, because Oryx is a .NET app and [.NET does not support QEMU](https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md).
@@ -162,8 +162,8 @@ The sample uses the following configurable settings in `local.settings.json`:
 
 All deployment methods have been fully tested against Azure and the LocalStack for Azure local emulator.
 
-> **Note**  
-> The first time you run Azure Functions on LocalStack for Azure, the emulator downloads a ZIP archive of the selected version of the [Azure Functions Core Tools](https://github.com/Azure/azure-functions-core-tools/tags) to build the container image that hosts your functions. By default, version 4.2.2 is used. You can override this by setting the AZURE_FUNCTIONS_CORE_TOOLS_VERSION environment variable. The archive is large (over 500 MB), so the initial download may take several minutes. Subsequent runs will use the cached copy.
+> [!NOTE]
+> The first time you run Azure Functions on LocalStack for Azure, the emulator downloads a ZIP archive of the selected version of the [Azure Functions Core Tools](https://github.com/Azure/azure-functions-core-tools/tags) to build the container image that hosts your functions. By default, version 4.15.1 is used (4.13.0 on an arm64 host). You can override this by setting the `LS_AZURE_FUNCTIONS_CORE_TOOLS_VERSION` environment variable on the emulator. The archive is large (over 500 MB), so the initial download may take several minutes. Subsequent runs will use the cached copy.
 
 ## Test
 
@@ -184,7 +184,7 @@ You can use [Azure Storage Explorer](https://learn.microsoft.com/en-us/azure/sto
 
 ![Azure Storage Explorer](./images/azure-storage-explorer.png)
 
-> **Note**  
+> [!TIP]
 > When sending commands to an emulated storage account, make sure to use the primary key generated by the emulator itself. For convenience, if you're connecting to the storage account directly with Azure Storage Explorer, you can use the default Azurite password. For more details, see [Connect to Azurite with SDKs and tools](https://learn.microsoft.com/en-us/azure/storage/common/storage-connect-azurite).
 
 You can expand the storage account to view the **Blob Containers**, **Queues**, and **Tables** created and used by this sample, as illustrated below:

samples/servicebus/java/README.md

@@ -33,7 +33,7 @@ The solution is composed of the following Azure resources:
 2. [Azure Service Bus Namespace](https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-messaging-overview): The messaging namespace that hosts the queue used by the application.
 3. [Azure Service Bus Queue](https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-queues-topics-subscriptions#queues): The `myqueue` queue used to send and receive messages.
 
-> **Note**
+> [!NOTE]
 > The Java application currently runs on the host machine. In a future iteration, it will be deployed to an emulator-hosted web app.
 
 ## Prerequisites
@@ -75,7 +75,7 @@ Deploy the application to LocalStack for Azure using one of these methods:
 
 All deployment methods have been fully tested against Azure and the LocalStack for Azure local emulator.
 
-> **Note**
+> [!NOTE]
 > When you deploy the application to LocalStack for Azure for the first time, the initialization process involves downloading and building Docker images. This is a one-time operation—subsequent deployments will be significantly faster. Depending on your internet connection and system resources, this initial setup may take several minutes.
 
 ## How It Works