This guide explains how to run e2e test steps and build jobs locally to debug failures before pushing to CI.
E2E tests run in AWS CodeBuild with specific build steps defined in codebuild_specs/*.yml. Each build spec calls functions from shared-scripts.sh. You can simulate these steps locally to debug issues.
Most e2e operations require AWS credentials. The repository uses ada (Amazon's credential management tool) for authentication, which is called automatically by the scripts.
Setup:
- Ensure you have
adaandmwinitinstalled - Create
scripts/.envfile with account details:# scripts/.env E2E_ACCOUNT_PROD=<account-id> E2E_ACCOUNT_BETA=<account-id>
- If you see authentication errors, run
mwinitin your terminal
Note: The scripts automatically call ada for credential refresh. You don't need to run ada commands manually.
What it does: Runs all unit tests with coverage in CI mode
Command:
yarn test-ciEquivalent to:
lerna run test --concurrency 4 -- --ci -iCommon issues:
- Coverage threshold failures: Check
jest.config.jsin the failing package - Pre-existing coverage issues may not be related to your changes
- To verify if an issue is pre-existing, test on the base branch
What it does: Checks code style and linting rules
Command:
yarn lint-checkCommon issues:
- Use
yarn lint-fixto auto-fix some issues - Some lint errors require manual fixes
- Check
.eslintrc.jsfor linting rules
What it does: Publishes packages to a local Verdaccio registry for e2e testing
Command:
# Start Verdaccio (in separate terminal)
yarn verdaccio-start
# Publish packages
yarn publish-to-verdaccio
# Stop Verdaccio when done
yarn verdaccio-stopCommon issues:
- Requires Verdaccio running locally
- May fail if packages have version conflicts
- Check
lerna.jsonfor version configuration
What it does: Builds all packages on Windows with Node.js 22 or later
Command (on Windows):
yarn production-build
yarn build-testsCommand (on macOS/Linux): Cannot be fully simulated on non-Windows systems. However, you can:
yarn production-build
yarn build-testsCommon issues:
- Path separator differences (Windows uses
\, Unix uses/) - Line ending differences (CRLF vs LF)
- Case-sensitive filesystem differences
- Windows-specific Node.js modules
What it does: Builds all packages on Linux
Command:
yarn production-build
yarn build-testsCommon issues:
- Build errors usually indicate TypeScript or dependency issues
- Check for missing dependencies in package.json files
yarn e2e-failed <batch-id>This shows which specific builds failed.
yarn e2e-logs <build-id>This downloads and displays the full build log.
Run the equivalent local command (see sections above) to reproduce the issue.
Before fixing, verify the issue exists on the base branch:
# Stash your changes
git stash
# Checkout base branch
git checkout dev
# Run the failing command
yarn <command>
# Restore your changes
git checkout <your-branch>
git stash pop# 1. Commit and push all changes
git push
# 2. Trigger e2e suite
yarn cloud-e2e
# 3. Monitor with auto-retry
yarn e2e-monitor <batch-id>You can run specific e2e test files locally:
# Run specific test file
cd packages/amplify-e2e-tests
yarn e2e src/__tests__/api_1.test.tsNote: Local e2e tests still require AWS credentials and will create real resources in your AWS account.
Symptoms:
- Timeout errors
- Credential expiration
- Quota/limit errors
Solution: Retry the build
yarn e2e-retry <batch-id>Symptoms:
- Test failures
- Build errors
- Linting errors
- Coverage threshold failures
Solution: Fix the code and re-run locally, then push and re-trigger e2e tests
Symptoms:
- Module not found errors
- Version conflicts
- Breaking API changes
Solution:
- Check if dependency upgrade is necessary
- Look for major version changes that may have breaking changes
- Consider pinning to a compatible version
The e2e workflow includes these build types:
build_linux- Build on Linux (not retried by monitor)build_windows- Build on Windows (not retried by monitor)test- Run unit tests (not retried by monitor)lint- Run linting (not retried by monitor)verify_yarn_lock- Verify yarn.lock consistencypublish_to_local_registry- Publish to Verdaccioamplify_e2e_tests_*- E2E test suites (multiple jobs)
Note: The monitor script skips auto-retrying build_linux, build_windows, test, and lint because failures in these are typically code-related and require fixes, not retries.
- Always test locally first before pushing to CI
- Check pre-commit hooks - they run tests automatically
- Monitor resource usage - e2e tests create real AWS resources
- Clean up resources - use cleanup scripts periodically
- Ensure Gen1 placeholder app - if
amplify initfails with a Gen1 new-customer restriction error in a fresh account, runyarn ensure-gen1-placeholder-appsfrompackages/amplify-e2e-tests(requires org root account credentials) to create the placeholder app in all accounts and regions - Check credentials - most failures are due to expired credentials
- Read the logs - build logs contain detailed error information
This is a generic error. Check the full output for the actual error message.
Often indicates a dependency version mismatch or breaking API change.
Check if this is a pre-existing issue by testing on the base branch. Coverage can change due to:
- Code changes
- Dependency updates affecting how coverage is calculated
- Test changes
Run yarn lint-fix to auto-fix some issues. Others require manual fixes.
If you see an error like Error: Execution failed: posix_spawnp failed originating from node-pty, the spawn-helper binary shipped with node-pty lost its execute permission (common after a fresh yarn install).
Fix:
chmod +x node_modules/node-pty/prebuilds/darwin-arm64/spawn-helperRun this from the repository root.
- DEPENDABOT.md - Dependency update workflow
- AGENTS.md - General agent workflow
- shared-scripts.sh - Build step implementations