Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Sync attachments to assets directory #254

Merged
merged 18 commits into from
Apr 10, 2024
Merged

feat: Sync attachments to assets directory #254

merged 18 commits into from
Apr 10, 2024

Conversation

tianfeng92
Copy link
Contributor

@tianfeng92 tianfeng92 commented Apr 4, 2024

Description

Control the sync assets feature using the SAUCE_SYNC_WEB_ASSETS global environment variable:

  • Resets the Playwright output directory.
  • Configures the sync asset directory for the Playwright reporter.

Feel free to suggest other env var name to replace SAUCE_SYNC_WEB_ASSETS.

Job example: https://app.saucelabs.com/tests/b7e69e6cc94f4616bec8c5f05b7a3824

@tianfeng92 tianfeng92 marked this pull request as ready for review April 4, 2024 23:56
@tianfeng92 tianfeng92 requested a review from a team as a code owner April 4, 2024 23:56
src/playwright-runner.ts Outdated Show resolved Hide resolved
src/playwright-runner.ts Outdated Show resolved Hide resolved
@tianfeng92 tianfeng92 requested a review from alexplischke April 5, 2024 16:43
if (
excludeParams.includes(key.toLowerCase()) ||
value === false ||
value === undefined ||
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? Because later it's going to stringify undefined 🤷‍♀️

procArgs.push(String(value));

@@ -175,7 +175,15 @@ async function getCfg(
runCfg.sauce = {};
}
runCfg.sauce.region = runCfg.sauce.region || 'us-west-1';
runCfg.playwrightOutputFolder = path.join(runCfg.assetsDir, 'test-results');
runCfg.playwrightOutputFolder =
suite.env?.SAUCE_SYNC_WEB_ASSETS?.toLowerCase() === 'true'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this will only work if and only if the customer has this env var defined as the string "true"? The schema for env is a simple object so we won't be able to provide any in-editor context/autocomplete for this value.

Do we want to relax this check and just check for a non empty string?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think set it to true is more accurate and doesn't cause further confusion like: what should I set? Let me try 1, yes, enabled and etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's your opinion @alexplischke ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not suggesting the value should only be 1 or yes or enabled. But let's say my configuration is

env:
  SAUCE_SYNC_WEB_ASSETS: enabled

Do we really want to ignore it just because its not set to exactly true? (Not a rhetorical question, honestly wondering).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But then the customer might want to try with disabled to disable it, which can't work as expected.

env:
  SAUCE_SYNC_WEB_ASSETS: disabled

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course. So what would be the least surprising behaviour?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, I don't feel that strongly one way or the other. If you think enabling if and only if set to true is better, let's go with that. We're gonna eventually transition to enabling it by default so this check is gonna be removed soon anyways.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. I think we should set the strict rules with documentation. No vague settings. But of course, this will be removed in the future so I think it's good to leave it like this 🙈

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't feel strongly either way as well. If you want to go the extra mile, you could do a check for 1, true, enable(d) and yes 😅 Externally we should only document the value "true".

@tianfeng92 tianfeng92 merged commit b49f447 into main Apr 10, 2024
29 checks passed
@tianfeng92 tianfeng92 deleted the DEVX-2834 branch April 10, 2024 16:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants