You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/playwright-testing/playwright-testing-reporting-with-sharding.md
+63-46Lines changed: 63 additions & 46 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ In this article, you learn how to use the Microsoft Playwright Testing service's
16
16
17
17
Playwright's sharding enables you to split your test suite to run across multiple machines simultaneously. This feature helps running tests in parallel.
18
18
19
-
You can use Playwright Testing's reporting feature to get a consolidated report of a test run with sharding. You need to make sure you set the variable `PLAYWRIGHT_SERVICE_RUN_ID` so that it remains same across all shards.
19
+
You can use Playwright Testing's reporting feature to get a consolidated report of a test run with sharding. You need to make sure the `runId` of the test run is same across all shards.
20
20
21
21
> [!IMPORTANT]
22
22
> Microsoft Playwright Testing is currently in preview. For legal terms that apply to Azure features that are in beta, in preview, or otherwise not yet released into general availability, see the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
@@ -27,65 +27,82 @@ You can use Playwright Testing's reporting feature to get a consolidated report
27
27
28
28
* Set up continuous end-to-end testing. Complete the [Quickstart: Set up continuous end-to-end testing with Microsoft Playwright Testing Preview](./quickstart-automate-end-to-end-testing.md) to set up continuous integration (CI) pipeline.
29
29
30
+
## Update playwright service configuration file
31
+
32
+
Add or update `runId` to `playwright.service.config.ts` file in your setup.
33
+
34
+
```typescript
35
+
.
36
+
.
37
+
.
38
+
exportdefaultdefineConfig(
39
+
config,
40
+
getServiceConfig(config, {
41
+
runId: process.env.PLAYWRIGHT_SERVICE_RUN_ID, //Set runId for the test run
42
+
}),
43
+
);
44
+
45
+
```
46
+
You can use `PLAYWRIGHT_SERVICE_RUN_ID` variable in your setup to ensure the `runId` remains same across all shards.
30
47
31
48
## Set up variables
32
49
33
-
The `PLAYWRIGHT_SERVICE_RUN_ID` variable is an identifier that is used by Playwright Testing service to distinguish between test runs. The results from multiple runs with same `RUN_ID` are reported to the same run on the Playwright portal.
50
+
The `runId` setting is be used as an identifier by Playwright Testing service to distinguish between test runs. The results from multiple runs with same `runId` are reported to the same run on the Playwright portal.
34
51
35
-
By default, a test run that uses reporting feature automatically generates a unique `RUN_ID` unless you explicitly set the value yourself. If the value of the variable remains same across runs, the results are reported together in the same run on the Playwright portal.
52
+
By default, a test run that uses reporting feature automatically generates a unique `runId` unless you explicitly set the value yourself. If the value of the variable remains same across runs, the results are reported together in the same run on the Playwright portal.
36
53
37
54
> [!Tip]
38
55
> If you use the cloud-hosted browsers provided by Microsoft Playwright Testing service to run your tests, you might have already set this variable. To avoid overwrites, make sure you set it only once.
39
56
40
57
41
-
While using sharding, make sure the same `RUN_ID` is set across all the shards for the results to be reported together.
58
+
While using sharding, make sure the same `runId` is set across all the shards for the results to be reported together. This can be achieved by using a variable `PLAYWRIGHT_SERVICE_RUN_ID` and setting this value same across all shards.
42
59
43
60
Here's an example of how you can set it in your pipeline via GitHub Actions.
44
61
45
62
```yml
46
-
name: Playwright Tests
47
-
on:
48
-
push:
49
-
branches: [ main, master ]
50
-
pull_request:
51
-
branches: [ main, master ]
52
-
workflow_dispatch:
53
-
strategy:
54
-
fail-fast: false
55
-
matrix:
56
-
shardIndex: [1, 2, 3, 4]
57
-
shardTotal: [4]
58
-
permissions:
59
-
id-token: write
60
-
contents: read
61
-
jobs:
62
-
test:
63
-
timeout-minutes: 60
64
-
runs-on: ubuntu-latest
65
-
steps:
66
-
- uses: actions/checkout@v3
67
-
- uses: actions/setup-node@v3
68
-
with:
69
-
node-version: 18
70
-
# This step is to sign-in to Azure to run tests from GitHub Action workflow.
71
-
# You can choose how set up Authentication to Azure from GitHub Actions, this is one example.
72
-
- name: Login to Azure with AzPowershell (enableAzPSSession true)
PLAYWRIGHT_SERVICE_RUN_ID: ${{ github.run_id }}-${{ github.run_attempt }}-${{ github.sha } #This Run_ID will be unique and will remain same across all shards
90
-
run: npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}
103
+
env:
104
+
# Regional endpoint for Microsoft Playwright Testing
PLAYWRIGHT_SERVICE_RUN_ID: ${{ github.run_id }}-${{ github.run_attempt }}-${{ github.sha } #This Run_ID will be unique and will remain same across all shards
107
+
run: npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}
@@ -158,6 +158,79 @@ Enable artifacts such as screenshot, videos and traces to be captured by Playwri
158
158
Once you collect these artifacts, attach them to the `TestContext` to ensure they are available in your test reports. For more information, see our [sample project for NUnit](https://aka.ms/mpt/nunit-sample)
159
159
::: zone-end
160
160
161
+
## Set up authentication
162
+
163
+
The CI machine running Playwright tests needs to authenticate with Playwright Testing service to get the browsers to run the tests and to publish the test results and arifacts back to the service.
164
+
165
+
The service offers two authentication methods: Microsoft Entra ID and Access Tokens. We strongly recommend using Microsoft Entra ID to authenticate your pipelines.
166
+
167
+
#### Set up authentication using Microsoft Entra ID
168
+
169
+
# [GitHub Actions](#tab/github)
170
+
171
+
If you are using GitHub Actions, you can connect to the service using GitHub OpenID Connect. Follow the steps below to set up the integration:
172
+
173
+
##### Prerequisites
174
+
175
+
**Option 1: Microsoft Entra application**
176
+
177
+
* Create a Microsoft Entra application with a service principal by [Azure portal](/entra/identity-platform/howto-create-service-principal-portal#register-an-application-with-microsoft-entra-id-and-create-a-service-principal), [Azure CLI](/cli/azure/azure-cli-sp-tutorial-1#create-a-service-principal), or [Azure PowerShell](/powershell/azure/create-azure-service-principal-azureps#create-a-service-principal).
178
+
179
+
* Copy the values for **Client ID**, **Subscription ID**, and **Directory (tenant) ID** to use later in your GitHub Actions workflow.
180
+
181
+
* Assign the `Owner` or `Contributor` role to the service principal created in the previous step. These roles must be assigned on the Playwright Testing workspace. For more details, refer to [How to manage access](./how-to-manage-access-tokens.md).
182
+
183
+
*[Configure a federated identity credential on a Microsoft Entra application](/entra/workload-id/workload-identity-federation-create-trust) to trust tokens issued by GitHub Actions to your GitHub repository.
184
+
185
+
**Option 2: User-assigned managed identity**
186
+
187
+
*[Create a user-assigned managed identity](/entra/identity/managed-identities-azure-resources/how-manage-user-assigned-managed-identities#create-a-user-assigned-managed-identity).
188
+
189
+
* Copy the values for **Client ID**, **Subscription ID**, and **Directory (tenant) ID** to use later in your GitHub Actions workflow.
190
+
191
+
* Assign the `Owner` or `Contributor` role to the user-assigned managed identity created in the previous step. These roles must be assigned on the Playwright Testing workspace. For more details, refer to [How to manage access](./how-to-manage-access-tokens.md).
192
+
193
+
*[Configure a federated identity credential on a user-assigned managed identity](/entra/workload-id/workload-identity-federation-create-trust-user-assigned-managed-identity) to trust tokens issued by GitHub Actions to your GitHub repository.
194
+
195
+
##### Create GitHub secrets
196
+
197
+
1. Add the values you got in the previous step as secrets to your GitHub repository. See [set up GitHub Action Secret](/azure/developer/github/connect-from-azure-openid-connect?branch=main#create-github-secrets). These variables will be used in the GitHub Action workflow in subsequest steps.
> For enhanced security, it is strongly recommended to use GitHub Secrets to store sensitive values rather than including them directly in your workflow file.
207
+
208
+
# [Azure Pipelines](#tab/pipelines)
209
+
210
+
If you are using Azure Pipelines, you can connect to the service using Service Connections. Follow the steps below to set up the integration:
211
+
212
+
1.[Create an app registration with workload identity federation](/azure/devops/pipelines/library/connect-to-azure?view=azure-devops#create-an-app-registration-with-workload-identity-federation-automatic). Select the subscription and resource group associated with your Playwright Testing workspace. Typically, the resource group has the same name as the Playwright Testing workspace.
213
+
214
+
2. Use this service connection in Azure Pipeline yaml file as shown in subsequent steps.
215
+
216
+
#### Set up authentication using access tokens
217
+
218
+
> [!CAUTION]
219
+
> We strongly recommend using Microsoft Entra ID for authentication to the service. If you are using access tokens, see [How to Manage Access Tokens](./how-to-manage-access-tokens.md)
220
+
221
+
You can generate an access token from your Playwright Testing workspace and use it in your setup. However, we strongly recommend Microsoft Entra ID for authentication due to its enhanced security. Access tokens, while convenient, function like long-lived passwords and are more susceptible to being compromised.
222
+
223
+
1. Authentication using access tokens is disabled by default. To use, [Enable access-token based authentication](./how-to-manage-authentication.md#enable-authentication-using-access-tokens)
224
+
225
+
2.[Set up authentication using access tokens](./how-to-manage-authentication.md#set-up-authentication-using-access-tokens)
226
+
227
+
3. Store the access token in a CI workflow secret and use it in the GitHub Actions workflow or Azure Pipeline yaml file.
228
+
229
+
| Secret name | Value |
230
+
| ----------- | ------------ |
231
+
|*PLAYWRIGHT_SERVICE_ACCESS_TOKEN*| Paste the value of Access Token you created previously. |
232
+
233
+
161
234
## Update the workflow definition
162
235
163
236
::: zone pivot="playwright-test-runner"
@@ -175,47 +248,51 @@ Update the CI workflow definition to run your Playwright tests with the Playwrig
175
248
176
249
# This step is to sign-in to Azure to run tests from GitHub Action workflow.
177
250
# Choose how to set up authentication to Azure from GitHub Actions. This is one example.
178
-
on:
179
-
push:
180
-
branches: [ main, master ]
181
-
pull_request:
182
-
branches: [ main, master ]
183
-
permissions: # Required when using Microsoft Entra ID to authenticate
# PLAYWRIGHT_SERVICE_ACCESS_TOKEN: $(PLAYWRIGHT_SERVICE_ACCESS_TOKEN) # Not recommended, use Microsoft Entra ID authentication.
427
+
349
428
inputs:
350
-
azureSubscription: My_Service_Connection # Service connection used to authenticate this pipeline with Azure to use the service
429
+
azureSubscription: My_Service_Connection # Service connection used to authenticate this pipeline with Azure to use the service using Microsoft Entra ID.
0 commit comments