Add E2E tests for DAG Runs page

[lin121291]

What change does this PR introduce?

Adds end-to-end (E2E) tests for the DAG runs page (/dag_runs) to improve test coverage of the UI.

What does this PR do?

New Files:

• airflow-core/src/airflow/ui/tests/e2e/pages/DagRunsPage.ts - Page Object Model for DAG runs page
• airflow-core/src/airflow/ui/tests/e2e/specs/dag-runs.spec.ts - Test specifications

Test Coverage (as per DAGRUNS-001):

• Navigate to DAG Runs page - Verifies page loads and table renders
• Verify run details display - Checks DAG ID, Run ID, State, Start Time, End Time
• Verify state visual distinction - Validates different states (success, failed, running) have distinct badge colors
• Verify filtering works - Ensures filter functionality is accessible and functional

Related Issues

Closes #59309

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[lin121291]

Hi @vatsrahul1001

The WebKit E2E tests are failing in CI while Chromium and Firefox pass.

Error: page.goto: Test timeout of 30000ms exceeded

This appears to be a WebKit-specific CI environment issue (network/timing), not a test logic problem.

Should I:

1. Increase timeout for WebKit?
2. Or is this a known issue that can be ignored?

Thanks!

[vatsrahul1001]

@lin121291 Thanks for this PR! A few things:

1. WebKit timeout - Add test.setTimeout(60_000) at describe level.

2. Create test data in beforeAll:

   • Trigger a DAG and wait for completion
   • Mark that run as "failed" using the API:
     await page.request.patch(
     /api/v2/dags/${dagId}/dagRuns/${runId},
     { data: { state: "failed" } }
     );
   • Trigger another run for "success" state
   • We need to also trigger multiple dags here so that in filtering test we can filter with different dag id
     This ensures runs exist for testing.

3. Remove fixed waits - Replace waitForTimeout(1000) with element waits.

4. Error handling in navigate() - Replace .catch(() => {}) with proper assertions.

5. Filter test - After clicking the filter, verify that results actually change or that the filter UI appears correctly. Let's start with filter of state and dag id

6. Add tests for paginations, by default pagination is 50 runs, but I think you can use offset and limit in your url to test this http://localhost:8080/dag_runs?offset=0&limit=3

Let me know if you have questions!

[vatsrahul1001]

@lin121291 can you resolve the comments, and we can merge post it

[lin121291]

@vatsrahul1001 All feedback addressed in the latest commit. Thanks for the detailed review!

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.