/gha-typescript-playwright

Exercise project for GitHub Actions: Playwright UI test automation using TypeScript

Primary LanguageTypeScript

GitHub Actions in action - Playwright Java Tests

This repository contains end-to-end UI tests using Playwright with TypeScript and Jest.


πŸš€ Getting Started

1️⃣ Prerequisites

  • Node.js (LTS version recommended)
  • IDE or editor of choice

2️⃣ Fork the repo

πŸ”— Documentation: Fork a repository

3️⃣ Clone the repo

git clone https://github.com/$yourGitHubUsername/gha-typescript-playwright.git
cd gha-typescript-playwright

4️⃣ Install Dependencies

npm install
npx playwright install --with-deps

5️⃣ Run Tests

npx playwright test

πŸ“ Slides

Link to slides


πŸ›  Exercises

Each exercise has:

  • Detailed instructions
  • Link(s) to relevant GitHub Actions (and other) documentation

πŸš€ Exercise 1: Create a Basic Workflow

πŸ“‚ Workflow file: .github/workflows/01-basic-workflow.yaml
πŸ’‘ Goal: Understand workflow structure and manually trigger a workflow.

πŸ“Œ Instructions

  1. Inside the .github/workflows/ directory, create a new file 01-basic-workflow.yaml.
  2. Define a workflow that:
    • Can be triggered manually
    • Runs a simple print command
  3. Commit & push the workflow.
  4. Trigger the workflow manually from GitHub Actions.
  5. Observe the logs.

πŸ”— Relevant Documentation:


πŸ›  Exercise 2: Run Playwright Tests in CI/CD

πŸ“‚ Workflow file: .github/workflows/02-run-tests.yaml
πŸ’‘ Goal: Run Playwright tests in GitHub Actions.

πŸ“Œ Instructions

  1. Create a workflow file that:
    • Runs Playwright tests on every push to main.
  2. Commit & push the workflow.
  3. Observe test execution in GitHub Actions logs.

πŸ”— Relevant Documentation:


πŸ›  Exercise 3: Cache Dependencies for Faster Builds

πŸ“‚ Workflow file: .github/workflows/03-cache-dependencies.yaml
πŸ’‘ Goal: Cache dependencies to speed up workflow execution.

πŸ“Œ Instructions

  1. Create a workflow file (based on 02-run-tests.yaml) that:
    • Caches dependencies to avoid reinstalling them on every run.
    • Restores the cache if available, otherwise installs dependencies as usual.
  2. Commit & push the workflow.
  3. Observe the caching mechanism in the GitHub Actions logs.

πŸ”— Relevant Documentation:


πŸ“Š Exercise 4: Upload Playwright Test Reports

πŸ“‚ Workflow file: .github/workflows/04-upload-reports.yaml
πŸ’‘ Goal: Store test results (screenshots, logs) as GitHub Actions artifacts.

πŸ“Œ Instructions

  1. Create a workflow file (based on 03-cache-dependencies.yaml), that uploads the following folders:
    • For TypeScript: playwright-report and test-results
    • For Java: target/reports and target/surefire-reports
  2. Commit & push changes. 3Run the tests and check artifacts in GitHub Actions UI.

πŸ”— Relevant Documentation:


πŸ“Œ Exercise 5: Show Test Report in GitHub UI

πŸ“‚ Workflow file: .github/workflows/05-show-report.yaml
πŸ’‘ Goal: Display test results directly in the GitHub Actions summary tab.

πŸ“Œ Instructions

  1. Create a workflow file (based on 03-cache-dependencies.yaml), that displays the HTML test report using an action such as phoenix-actions/test-reporting@v15 or a similar alternative.
    • For Java: Use the report file target/reports/surefire.html
    • For TypeScript: Use the report file playwright-report/index.html
  2. Commit & push changes.
  3. Observe the test report preview in the GitHub Actions summary tab.

πŸ”— Relevant Documentation:


πŸ”— Exercise 6: Run Tests on Pull Requests

πŸ“‚ Workflow file: .github/workflows/06-run-on-pr.yaml
πŸ’‘ Goal: Automatically test pull requests.

πŸ“Œ Instructions

  1. Create a workflow file (based on 03-cache-dependencies.yaml)
  2. Modify the workflow’s on: field to trigger tests on pull requests.
  3. Create a new branch, modify a test, and open a pull request.
  4. Observe the test execution in GitHub Actions.

πŸ”— Relevant Documentation:


πŸ“Œ Exercise 7: Fail PRs if Tests Fail

πŸ’‘ Goal: Prevent merging if tests fail.

πŸ“Œ Instructions

  1. Ensure your workflow is set up to run tests on pull requests (e.g., using your existing .github/workflows/05-run-on-pr.yaml file).
  2. In GitHub, enable "Require status checks to pass before merging" (classic protection rule) for your branch.
  3. Test the setup by pushing a commit that intentionally fails a test.
  • ❗Note: This setup only works if you have a paid GitHub plan.
  • πŸ’‘Note: For organizations on GitHub Team/Enterprise, you can also use branch rulesets.

πŸ”— Relevant Documentation:


πŸ”§ Exercise 8: Create a Custom GitHub Action

πŸ“‚ Workflow file: .github/workflows/08-custom-action.yaml
πŸ’‘ Goal: Create and use a custom GitHub Action.

πŸ“Œ Instructions

  1. Edit your workflow to simulate Playwright test output and use the custom action to process it.

    See hints

    Create a directory test-results and generates a test report file report.txt inside it.
    Write fake test results to the file, simulating passed and failed tests.

  2. Inside .github/actions/, create a folder playwright-summary.

  3. Inside the folder, create action.yaml and define a composite action that processes Playwright test results.

    See hints

    The custom action processes the test-results/report.txt file, extracts its content, and formats a summary for display in GitHub job summaries.

  4. Commit & push your changes.

  5. Observe the formatted test summary in the GitHub Actions logs.

✨ Note: Feel free to come up with an own idea and implement it as custom action.

πŸ”— Relevant Documentation:


⏰ Exercise 9: Scheduled Regression Suites

πŸ“‚ Workflow file: .github/workflows/09-scheduled-regression.yaml
πŸ’‘ Goal: Set up a workflow that automatically runs on a weekday schedule.

πŸ“Œ Instructions

  1. Create a new workflow file 09-scheduled-regression.yaml (based on any of the already existing workflows)
  2. Modify the workflow to trigger automatically on a schedule (weekdays at 1 AM UTC).
  3. Commit & push your changes.
  4. Observe test execution in GitHub Actions logs once the scheduled time passes.

❗ Note: To really observe the execution, set the trigger to execute shortly after you will have pushed.

πŸ”— Relevant Documentation:


🐳 Exercise 10: Containerized Testing with Docker

πŸ“‚ Workflow file: .github/workflows/10-containerized-testing.yaml
πŸ’‘ Goal: Run tests inside Docker containers to ensure consistency across different environments.

πŸ“Œ Instructions

  1. Create a workflow 10-containerized-testing.yaml file (based on 03-cache-dependencies.yaml) that:
    • Uses Docker containers to run tests.
    • Runs on every push and pull request.
  2. Modify your test setup to execute inside a Docker container.
    • For Java: Use a maven:latest container to run tests.
    • For TypeScript: Use a node:latest container with Playwright pre-installed.
  3. Ensure dependencies are installed inside the container.
  4. Commit & push your changes.
  5. Observe the test execution logs inside the container.

πŸ”— Relevant Documentation:


⚑ Exercise 11: Parallel Test Execution

πŸ“‚ Workflow file: .github/workflows/11-parallel-tests.yaml
πŸ’‘ Goal: Configure a matrix strategy in GitHub Actions to run Playwright tests concurrently across different browsers or environments.

πŸ“Œ Instructions

  1. Create a new workflow file 11-parallel-tests.yaml (based on 03-cache-dependencies.yaml).
  2. Use a matrix strategy to define multiple browsers (e.g., chromium, firefox, webkit)
    • For Java: pass a system property (e.g. -Dplaywright.browserName=${{ matrix.browser }}).
    • For TypeScript: pass the browser name to npx playwright test (e.g. --browser ${{ matrix.browser }}).
  3. Java only: Update your project files so tests can pick the correct browser:
    • Open src/test/java/dev/christianbaumann/PlaywrightTest.java
    • Uncomment the second @BeforeAll method and comment out the default one
  4. Commit & push the new workflow (and any modified files).
  5. Observe the concurrent runs in GitHub Actions. Each job in the matrix should execute in parallel, one for each browser/ environment.

πŸ”— Relevant Documentation:


🏁 Exercise 12: Cross-Platform Parallel Testing

πŸ“‚ Workflow file: .github/workflows/12-cross-platform-parallel.yaml
πŸ’‘ Goal: Execute tests in parallel across all combinations of Ubuntu, Windows, Mac with Chromium, Firefox, and Webkit.

πŸ“Œ Instructions

  1. Create a workflow (based on 11-parallel-tests.yaml) file that:
    • Runs tests in parallel across Ubuntu, Windows, and Mac.
    • Tests each browser: Chromium, Firefox, and Webkit.
    • Uses a matrix strategy to cover all combinations.
  2. Java: Keep the changes in src/test/java/dev/christianbaumann/PlaywrightTest.java from Exercise 11
  3. Commit & push the workflow.
  4. Observe the test execution across different platforms and browsers.

πŸ”— Relevant Documentation:


βš™οΈ Exercise 13: Debugging GitHub Actions Workflows

πŸ“‚ Workflow file: .github/workflows/13-debugging.yaml
πŸ’‘ Goal: Learn how to troubleshoot and debug GitHub Actions workflows effectively.

πŸ“Œ Instructions

  1. Create a new workflow file 13-debugging.yaml.
  2. Add a job that prints environment variables and debug logs using ACTIONS_STEP_DEBUG.
  3. Introduce an intentional failure (e.g., running a non-existent command) and observe error messages.
  4. Enable debug logging in GitHub Actions settings.
  5. Rerun the failed workflow with debugging enabled and analyze the logs.
  6. Fix the issue and confirm a successful run.

πŸ“ Relevant Documentation:


πŸ”‘ Exercise 14: Using Environment Variables and Secrets

πŸ“‚ Workflow file: .github/workflows/14-env-secrets.yaml
πŸ’‘ Goal: Store and use environment variables and secrets securely in workflows.

πŸ“Œ Instructions

  1. Create a new workflow file 14-env-secrets.yaml.
  2. Define environment variables inside a job.
  3. Store a GitHub Actions secret (MY_SECRET) in the repository settings.
  4. Access the secret in a workflow using ${{ secrets.MY_SECRET }}.
  5. Print environment variables but ensure secrets are not exposed in logs.
  6. Confirm that the workflow executes successfully without revealing sensitive information.

πŸ“ Relevant Documentation: