Skip to content

E2e test#8632

Closed
ryanfkeller wants to merge 5 commits into
hackforla:gh-pagesfrom
ryanfkeller:e2e-test
Closed

E2e test#8632
ryanfkeller wants to merge 5 commits into
hackforla:gh-pagesfrom
ryanfkeller:e2e-test

Conversation

@ryanfkeller
Copy link
Copy Markdown
Member

What changes did you make?

  • Added Playwright E2E test infrastructure (tests/e2e/) with Docker Compose integration
  • Added GitHub Actions workflow to run E2E tests on PRs
  • Fixed head.html to use relative paths for local assets (CSS, JS, favicon)

Why did you make the changes (we will use this info to test)?

  • E2E tests let us test user-facing site behavior (filtering, search, mobile interactions) against the built site without the complexity of mocking Jekyll/Liquid data
  • The head.html fix makes sure local assets resolve correctly if the site is served from a different location than the configured url (i.e. configured as localhost, served into Docker container)

Screenshots of Proposed Changes To The Website (if any)

  • No visual changes to the website

Notes:

  • Tests run in Docker via docker compose up hfla_e2e. The site is served using the existing hfla_site image, with a Playwright container added alongside it that runs the tests.

  • I have checked this PR for CodeQL alerts and none were found.

New hfla_e2e container based on playwright:v1.59.1:jammy. Uses the e2e profile so that devs can still use "docker compose up" to only launch the hfla_site and not run tests. Container depends on hfla_test, and command waits for hfla_site:4000 to be present before running tests.

Container is launchable with > docker compose up hfla_e2e

On a local machine, first launch of hfla_e2e also launches hfla_site, which builds the site. Subsequent runs use the existing hfla_site build. One thing to note is that if hfla_site source is updated, there's a race condition between the site being updated and hfla_e2e being run again. If hfla_e2e is run immediately after a change, it will be run on the stale (published) version of the site, and won't block waiting on the build to finish.
Absolute urls are appropriate for metadata, but using them with local assets makes those assets break when the site isn't served from the configured url (i.e. localhost). Using relative paths means that the asset url will always match the served site url.

This was discovered while setting up the e2e tests -- utils.js was silently failing to load because absolute_url baked in localhost:4000 to the utils url which doesn't resolve in the container network.
@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 9, 2026

Want to review this pull request? Take a look at this documentation for a step by step guide!


From your project repository, check out a new branch and test the changes.

git checkout -b ryanfkeller-e2e-test gh-pages
git pull https://github.com/ryanfkeller/website.git e2e-test

@ryanfkeller ryanfkeller closed this May 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

1 participant