feat: add `@playwright/test` e2e test setup

[ndom91]

Description

• Adds @playwright/test E2E test-runner and framework
• new npm scripts
  • test:e2e - run "headless" tests with playwright
  • test:e2e:run - run webapp with tauri mocking enabled (vite dev --mode testing)
  • test:e2e:watch - run with playwright "ui mode" enabled, see screenshot below, good for development
• Adds dummy initial test to check if page renders and initial changed file from fixtures are shown

• Adds e2e.yml github action ("Playwright Test") to run tests in CI (Example run here)
• Triggers on:
  • push to master
  • pull_requests to master
  • Cron schedule at 6:00 daily
  • Manual (workflow_dispatch)
  • Obviously feel free to remove any you may or may not need
• GHA failures will generate a report (zip file) that can be downloaded from the GHA run "summary" screen. They can then be uploaded and viewed at https://trace.playwright.dev to get an interactive viewer just like the local one shown above. See demo trace.zip here.

Potential Follow-up

• GitHub reporter to comment status on PR's - https://github.com/estruyf/playwright-github-actions-reporter

Challenges

• Mocking multiple use-cases; For example, we can set it to answer invoke('get_base_branch_data') with a certain fixture once, but if we want to test a different case where the underlying base branch data is different, or missing, etc. How should we do that? :thinking:
  • Idea: maybe just split it up by projects? If we select a different project, that'll have different branches, etc. it'll request and we can filter on that and respond with the correct one for each test case.
• There's an issue with the left-most navigation panel not rendering in the mocked mode (test:e2e:run), but it's not erroring out or indicating anything else that may be missing
• Also wasn't sure how best to type these fixture objects. I basically wanted to do the opposite of class-transformers plainToInstance, but in Typescript. We can't just use the class as type here because the class properties are all typed for after the transformation and these fixture objects are the raw data as is sent from the BE. Basically we need a TS version of the rust structs for these objects :joy:
• There's definitely a better way to structure the mocked invoke return values (/app/src/lib/testing/index.ts), but this definitely covered the base use-case. A simple switch case statement is tough because a lot of these require a secondary value you're comparing against (i.e. cmd === 'git_head' && args.id === 'abc123'). But maybe some nested switch statements (?)

[gitguardian[bot]]

⚠️ GitGuardian has uncovered 4 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
-		Generic High Entropy Secret	72be19a3f211a80bd08a2fd7d1f2885de23be8c4	app/src/lib/testing/fixtures.ts	View secret
-		Generic High Entropy Secret	a6968438a2fb4f9eeb86611b28eaf94e8499240b	app/src/lib/testing/fixtures.ts	View secret
-		Generic High Entropy Secret	a6968438a2fb4f9eeb86611b28eaf94e8499240b	app/src/lib/testing/fixtures.ts	View secret
-		Generic High Entropy Secret	0f9e5043a242c69573a62c386ebe23ca205ebaee	app/src/lib/testing/fixtures.ts	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[mtsgrd]

Basically we need a TS version of the rust structs for these objects

Have you considered generating them? https://github.com/oscartbeaumont/tauri-specta