Skip to content

fix: point webdriver CI tests at the live production URL - #25688

Open
akashreddy-nr wants to merge 3 commits into
mainfrom
fix/webdriver-dead-url
Open

akashreddy-nr wants to merge 3 commits into
mainfrom
fix/webdriver-dead-url

Conversation

@akashreddy-nr

Copy link
Copy Markdown
Contributor

Summary

  • The "webdriver test" check has been failing on every PR to `main` for at least the last two weeks, regardless of content — confirmed by checking the last 15 runs of .github/workflows/webdriver.yml, all failures.
  • Root cause: webdriver-desktop.mjs / webdriver-mobile.mjs hardcode https://develop--docs-website-netlify.netlify.app/ as the test target. That branch-deploy alias no longer resolves (confirmed 404 via direct fetch, as does main--docs-website-netlify.netlify.app), while the bare production alias https://docs-website-netlify.netlify.app/ is live and serves the expected /docs/mdx-test-page/ content (verified the collapser markup renders there).
  • Fix: point both scripts at the production alias instead of the dead branch-deploy alias.

Test plan

  • Confirm the "webdriver test" check passes on this PR.

develop--docs-website-netlify.netlify.app and main--docs-website-netlify.netlify.app
both 404 (confirmed via direct fetch) — that branch-deploy alias no
longer exists for this site, while the bare production alias
(docs-website-netlify.netlify.app) is live. This made the "webdriver
test" check fail on every PR to main regardless of content, going
back at least two weeks.
@akashreddy-nr
akashreddy-nr requested a review from a team as a code owner September 14, 2026 16:46
@github-actions

Copy link
Copy Markdown
Contributor

Hi @akashreddy-nr 👋

Thanks for your pull request! Your PR is in a queue, and a writer will take a look soon. We generally publish small edits within one business day, and larger edits within three days.

Please ensure the propsed changes look good by building it first in your local environment. Refer to this contribution guide to get the site up and running in your local.

If you really require a preview url, reach out to one of the writers and they will generate one for you.

Testing against the real production URL (previous commit) surfaced a
genuine gap: on the iPhone 12 Pro viewport, the Osano cookie consent
banner overlaps the homepage doc tile after scrollIntoView, so the
click lands on the banner instead — ElementClickInterceptedError.
Dismiss the banner first, same as a real user would.
The previous selector guessed at an osano-cm-accept* class that
doesn't exist in this deployment. The rendered banner exposes an
aria-label="Close this consent banner" on its close control, which is
a stable, accessible selector to target instead of guessing markup.
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.

2 participants