FAQ

Can I run on forks?

Yes, but GitHub’s security model limits secrets on untrusted forks. For visual testing CI/CD workflows, that means your SCANU_TOKEN may not be available on external pull requests by default. The safest pattern is to run full automated screenshot diff checks on trusted branches, protected environments, or internal mirror PRs where secrets are intentionally available. For public repositories, you can still run reduced validation on forks and keep baseline screenshot comparison enforcement on trusted pipelines.

This split approach prevents token leakage while preserving cross browser layout testing quality gates before merge. If your team relies on strict UI regression testing, document fork policy clearly so contributors know when visual checks run and how to request a trusted re-run. Consistent policy matters as much as tooling for dependable detect UI bugs automatically workflows.

Can I run on self-hosted runners?

Yes. Self-hosted runners are supported as long as they can reach both your target URLs and the ScanU API endpoints over HTTPS. For stable visual regression testing tools behavior, keep runner OS images consistent, pin browser versions where applicable, and avoid background processes that change rendering performance during capture. Deterministic infrastructure directly improves baseline screenshot comparison quality and reduces flaky diffs.

Teams often choose self-hosted runners for network control, compliance, or pre-production access. If you do, monitor runner health, CPU pressure, and outbound firewall rules so visual testing ci cd jobs do not fail intermittently. A healthy runner fleet plus predictable environment settings provides better automated screenshot diff reliability than ad-hoc infrastructure.

How to test only selected pages?

Use the action input urls to define exactly which pages are included in each run. This is the recommended way to focus visual regression testing on high-impact journeys such as landing, signup, checkout, and dashboard entry points. Narrow scopes keep automated screenshot diff runs fast and make review workloads manageable.

A practical strategy is to maintain two suites: a small PR suite for quick baseline screenshot comparison on critical pages, and a broader scheduled suite for deeper cross browser layout testing. This gives you fast developer feedback while still detecting long-tail UI changes. As your app evolves, revisit URL lists quarterly to ensure your detect ui bugs automatically coverage reflects current business priorities.

Does it support monorepos?

Yes. ScanU works well in monorepos when workflow triggers are scoped to frontend paths. Configure your CI rules so visual testing ci cd jobs run only when relevant UI packages change. This keeps screenshot budgets efficient and avoids unnecessary baseline updates from backend-only commits.

In larger monorepos, teams often map separate ScanU projects to separate apps or brands, each with its own baseline screenshot comparison history and page list. That structure improves ownership and makes automated screenshot diff triage faster. Combine path- based triggers with clear project naming conventions so regressions are routed to the right team immediately.

How do I view results in PR?

The GitHub Action posts a ScanU pull request comment summarizing run status, changed pages, and links to detailed visual reports. On re-runs, the same comment is updated so reviewers do not need to hunt through long threads. This workflow centralizes baseline vs current screenshot comparison evidence directly where code review happens.

For best results, define team rules for interpreting outcomes: when to approve intentional design updates, when to block merges, and when to request follow-up UI fixes. Clear review criteria turns visual regression testing with playwright and ScanU outputs into predictable release decisions rather than subjective debates. Consistent PR review is the final step in reliable detect ui bugs automatically processes.