Add playwright integration testing

[drewbo]

Investigate adding cypress post #3947 #4014

Notes

• https://www.cypress.io/

Acceptance Criteria

• Setup CI/CD to run the test
• Create a skeleton test to load the home page
• Research possible auth methods

[drewbo]

Adding some notes here as I research further:

Test Runner Selection

There are roughly 3 options for running e2e browser tests:

• Cypress: great option but some of the features I'd like (test recording) require use of their cloud. There is a fully open-source solution (https://sorry-cypress.dev/) that warrants a look.
• Playwright: another good option although my impression is that it has fewer features and a little bit more setup
• Selenium: not specifically a test runner but more of a "browser automation tool" that people often use for testing. Likely requires the most setup but with the most flexibility.

My instinct here is to investigate "sorry-cypress" and see if we can get something running quickly with that.

Artifact Storage

By design, Concourse does not support integrated artifact storage. So we need to find a place to put our test results if we want more than console output. My inclination to start is to write the results to a centralized location on S3: maybe at best we can generate pre-signed URLs for easy, temporary download

[apburnes]

The https://sorry-cypress.dev/ offering requires MongoDB which is currently not available in our brokered database offerings.

[apburnes]

For the test runners, exploring Cypress sans (https://sorry-cypress.dev/) and Playwright would be the better options since they have built-in test runners and would be a lower setup and maintenance lift than Selenium

Artifact storage in S3 is our best(only) option. Generating pre-signed URLs for easy, temporary download or a simple search and download tool are two options with minimal lift.

[drewbo]

PR up at: #4285, working example on CI: https://ci.fr.cloud.gov/teams/pages/pipelines/core/jobs/e2e-test/builds/24?vars.deploy-env=%22dev%22

The only issue I'm running into now is naming the report. Concourse is weirdly paternalistic about giving access to the $BUILD_NAME variable. Trying to use the git branch is difficult because the git-resource merges to main. Open to naming ideas.

These variables should be used solely for annotating things with metadata for traceability, i.e. for linking to the build in an alert or annotating an automated commit to facilitate its origin discovery. They should not be used to emulate versioning (e.g. by using the increasing build number). They are not provided to task steps to avoid this anti-pattern.

[apburnes]

What about a combo of date and git sha or git message?

[drewbo]

Closed via #4102