feat(api): add explicit async testInfo.attach
We add an explicit async API for attaching file paths (and Buffers) to
tests that can be awaited to help users ensure they are attaching files
that actually exist at both the time of the invocation and later when
reporters (like the HTML Reporter) run and package up test artifacts.
This is intended to help surface attachment issues as soon as possible
so you aren't silently left with a missing attachment
minutes/days/months later when you go to debug a suddenly breaking test
expecting an attachment to be there.
NB: The current implemntation incurs an extra file copy compared to
manipulating the raw attachments array. If users encounter performance
issues because of this, we can consider an option parameter that uses
rename under the hood instead of copy. However, that would need to be
used with care if the file were to be accessed later in the test.
1. Fixtures defined in test.extend() can now have `{ option: true }` configuration that makes them overridable in the config. Options support all other properties of fixtures - value/function, scope, auto.
```
const test = base.extend<MyOptions>({
foo: ['default', { option: true }],
});
```
2. test.declare() and project.define are removed.
3. project.use applies overrides to default option values and nothing else. Any test.extend() and test.use() calls take priority over config options.
Required user changes: if someone used to define fixture options with test.extend(), overriding them in config will stop working. The solution is to add `{ option: true }`.
```
// Old code
export const test = base.extend<{ myOption: number, myFixture: number }>({
myOption: 123,
myFixture: ({ myOption }, use) => use(2 * myOption),
});
// New code
export const test = base.extend<{ myOption: number, myFixture: number }>({
myOption: [123, { option: true }],
myFixture: ({ myOption }, use) => use(2 * myOption),
});
```
This patch:
- removes the Visual Regression bits from the images. These will
probably be added back when it's ready for the prime time.
* removes VNC && noVNC
* removes Playwright Agent
- cleans up apt caches
This drops image size from 2.03GB to 1.91GB.
This patch:
- removes the "is this upstream check?" when publishing daily version
- fixes the bug when manually triggered builds were pushed under @beta
tag
Drive-by: rename "tip-of-tree" flag to "next" for consistency.
When fixture value `R` is a function, TypeScript sometimes confuses
function `R` and function `async ({}, use) => {}`. This leads to
`any` types in the latter because it could be either of the functions
as TS thinks.
The solution is to only accept the second syntax, assuming that noone
passes fixture value that is a function as is:
```js
// This will stop working.
test.extend<{ foo: (x: number) => number }>({
foo: x => 2 * x,
});
// This will get inferred types and autocomplete.
test.extend<{ foo: (x: number) => number }>({
foo: async ({}, use) => {
await use(x => 2 * x);
},
});
```
This patch adds a general-purpose grid framework to parallelize
Playwright across multiple agents.
This patch adds two CLI commands to manage grid:
- `npx playwright experimental-grid-server` - to launch grid
- `npx playwrigth experimental-grid-agent` - to launch agent in a host
environment.
Grid server accepts an `--agent-factory` argument. A simple
`factory.js` might look like this:
```js
const child_process = require('child_process');
module.exports = {
name: 'My Simple Factory',
capacity: Infinity, // How many workers launch per agent
timeout: 10_000, // 10 seconds timeout to create agent
launch: ({agentId, gridURL, playwrightVersion}) => child_process.spawn(`npx`, [
'playwright'
'experimental-grid-agent',
'--grid-url', gridURL,
'--agent-id', agentId,
], {
cwd: __dirname,
shell: true,
stdio: 'inherit',
}),
};
```
With this `factory.js`, grid server could be launched like this:
```bash
npx playwright experimental-grid-server --factory=./factory.js
```
Once launched, it could be used with Playwright Test using env variable:
```bash
PW_GRID=http://localhost:3000 npx playwright test
```
This is an attempt to improve video performance when encoding
does not keep up with frames. This situation can be reproduced
by running multiple encoders at the same time.
Added `utils/video_stress.js` to manually reproduce this issue.
Observing ffmpeg logs, it does not do any encoding initially and
instead does "input analysis / probing" that detects fps and other
parameters. By the time it starts encoding (launches vpx and creates
the video file), we already have many frames in the buffer.
Reducing probing helps:
`-avioflags direct -fpsprobesize 0 -probesize 32 -analyzeduration 0`
Another issue observed is questionable default `-threads` value.
We compile without threads support, so logs say "using emulated threads".
For some reason, setting explicit `-threads 1` (or any other value)
makes it better when cpu is loaded.
