Add CI workflow for UI e2e tests

[vatsrahul1001]

This PR adds CI workflow for UI end-to-end tests introduced in #58548.

Changes

Self-contained test execution

• breeze testing ui-e2e-tests now automatically starts Airflow with docker-compose

Workflow Integration:

• Added run-ui-e2e-tests selective check that triggers when UI files change
• Integrated ui-e2e-tests.yml into additional-prod-image-tests.yml
• Kept workflow_dispatch for manual triggering

Testing

Run locally:
breeze testing ui-e2e-tests

Also Tested in CI as current PR has UI changes

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[vatsrahul1001]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

@pierrejeambrun updated workflow to run for every UI changes with all browsers

[potiuk]

Nice!

[potiuk]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

We can also split them to paralel suites using matrix job, this way the elapsed time will be shorter, we will increase build time spent, but we are still way below the limits that ASF has per-project. We did it successfully for a number of other jobs.

[jscheffl]

@vatsrahul1001 seems canary tests are now broken in Chromium, can you check what is broken (I do not understand the root of the problem :-D need to lern how this works...) --> https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

[vatsrahul1001]

https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

Looking into this @jscheffl

[vatsrahul1001]

This PR adds CI workflow for UI end-to-end tests introduced in #58548.

Changes

Self-contained test execution

• breeze testing ui-e2e-tests now automatically starts Airflow with docker-compose

Workflow Integration:

• Added run-ui-e2e-tests selective check that triggers when UI files change
• Integrated ui-e2e-tests.yml into additional-prod-image-tests.yml
• Kept workflow_dispatch for manual triggering

Testing

Run locally:
breeze testing ui-e2e-tests

Also Tested in CI as current PR has UI changes

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[vatsrahul1001]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

@pierrejeambrun updated workflow to run for every UI changes with all browsers

[potiuk]

Nice!

[potiuk]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

We can also split them to paralel suites using matrix job, this way the elapsed time will be shorter, we will increase build time spent, but we are still way below the limits that ASF has per-project. We did it successfully for a number of other jobs.

[jscheffl]

@vatsrahul1001 seems canary tests are now broken in Chromium, can you check what is broken (I do not understand the root of the problem :-D need to lern how this works...) --> https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

[vatsrahul1001]

https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

Looking into this @jscheffl

[vatsrahul1001]

This PR adds CI workflow for UI end-to-end tests introduced in #58548.

Changes

Self-contained test execution

• breeze testing ui-e2e-tests now automatically starts Airflow with docker-compose

Workflow Integration:

• Added run-ui-e2e-tests selective check that triggers when UI files change
• Integrated ui-e2e-tests.yml into additional-prod-image-tests.yml
• Kept workflow_dispatch for manual triggering

Testing

Run locally:
breeze testing ui-e2e-tests

Also Tested in CI as current PR has UI changes

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[vatsrahul1001]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

@pierrejeambrun updated workflow to run for every UI changes with all browsers

[potiuk]

Nice!

[potiuk]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

We can also split them to paralel suites using matrix job, this way the elapsed time will be shorter, we will increase build time spent, but we are still way below the limits that ASF has per-project. We did it successfully for a number of other jobs.

[jscheffl]

@vatsrahul1001 seems canary tests are now broken in Chromium, can you check what is broken (I do not understand the root of the problem :-D need to lern how this works...) --> https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

[vatsrahul1001]

https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

Looking into this @jscheffl

[vatsrahul1001]

This PR adds CI workflow for UI end-to-end tests introduced in #58548.

Changes

Self-contained test execution

• breeze testing ui-e2e-tests now automatically starts Airflow with docker-compose

Workflow Integration:

• Added run-ui-e2e-tests selective check that triggers when UI files change
• Integrated ui-e2e-tests.yml into additional-prod-image-tests.yml
• Kept workflow_dispatch for manual triggering

Testing

Run locally:
breeze testing ui-e2e-tests

Also Tested in CI as current PR has UI changes

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[vatsrahul1001]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

@pierrejeambrun updated workflow to run for every UI changes with all browsers

[potiuk]

Nice!

[potiuk]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

We can also split them to paralel suites using matrix job, this way the elapsed time will be shorter, we will increase build time spent, but we are still way below the limits that ASF has per-project. We did it successfully for a number of other jobs.

[jscheffl]

@vatsrahul1001 seems canary tests are now broken in Chromium, can you check what is broken (I do not understand the root of the problem :-D need to lern how this works...) --> https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

[vatsrahul1001]

https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

Looking into this @jscheffl

[vatsrahul1001]

This PR adds CI workflow for UI end-to-end tests introduced in #58548.

Changes

Self-contained test execution

• breeze testing ui-e2e-tests now automatically starts Airflow with docker-compose

Workflow Integration:

• Added run-ui-e2e-tests selective check that triggers when UI files change
• Integrated ui-e2e-tests.yml into additional-prod-image-tests.yml
• Kept workflow_dispatch for manual triggering

Testing

Run locally:
breeze testing ui-e2e-tests

Also Tested in CI as current PR has UI changes

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[vatsrahul1001]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

@pierrejeambrun updated workflow to run for every UI changes with all browsers

[potiuk]

Nice!

[potiuk]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

We can also split them to paralel suites using matrix job, this way the elapsed time will be shorter, we will increase build time spent, but we are still way below the limits that ASF has per-project. We did it successfully for a number of other jobs.

[jscheffl]

@vatsrahul1001 seems canary tests are now broken in Chromium, can you check what is broken (I do not understand the root of the problem :-D need to lern how this works...) --> https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

[vatsrahul1001]

https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

Looking into this @jscheffl

[vatsrahul1001]

This PR adds CI workflow for UI end-to-end tests introduced in #58548.

Changes

Self-contained test execution

• breeze testing ui-e2e-tests now automatically starts Airflow with docker-compose

Workflow Integration:

• Added run-ui-e2e-tests selective check that triggers when UI files change
• Integrated ui-e2e-tests.yml into additional-prod-image-tests.yml
• Kept workflow_dispatch for manual triggering

Testing

Run locally:
breeze testing ui-e2e-tests

Also Tested in CI as current PR has UI changes

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[vatsrahul1001]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

@pierrejeambrun updated workflow to run for every UI changes with all browsers

[potiuk]

Nice!

[potiuk]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

We can also split them to paralel suites using matrix job, this way the elapsed time will be shorter, we will increase build time spent, but we are still way below the limits that ASF has per-project. We did it successfully for a number of other jobs.

[jscheffl]

@vatsrahul1001 seems canary tests are now broken in Chromium, can you check what is broken (I do not understand the root of the problem :-D need to lern how this works...) --> https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

[vatsrahul1001]

https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

Looking into this @jscheffl

[vatsrahul1001]

This PR adds CI workflow for UI end-to-end tests introduced in #58548.

Changes

Self-contained test execution

• breeze testing ui-e2e-tests now automatically starts Airflow with docker-compose

Workflow Integration:

• Added run-ui-e2e-tests selective check that triggers when UI files change
• Integrated ui-e2e-tests.yml into additional-prod-image-tests.yml
• Kept workflow_dispatch for manual triggering

Testing

Run locally:
breeze testing ui-e2e-tests

Also Tested in CI as current PR has UI changes

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[vatsrahul1001]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

@pierrejeambrun updated workflow to run for every UI changes with all browsers

[potiuk]

Nice!

[potiuk]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

We can also split them to paralel suites using matrix job, this way the elapsed time will be shorter, we will increase build time spent, but we are still way below the limits that ASF has per-project. We did it successfully for a number of other jobs.

[jscheffl]

@vatsrahul1001 seems canary tests are now broken in Chromium, can you check what is broken (I do not understand the root of the problem :-D need to lern how this works...) --> https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

[vatsrahul1001]

https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

Looking into this @jscheffl

[vatsrahul1001]

This PR adds CI workflow for UI end-to-end tests introduced in #58548.

Changes

Self-contained test execution

• breeze testing ui-e2e-tests now automatically starts Airflow with docker-compose

Workflow Integration:

• Added run-ui-e2e-tests selective check that triggers when UI files change
• Integrated ui-e2e-tests.yml into additional-prod-image-tests.yml
• Kept workflow_dispatch for manual triggering

Testing

Run locally:
breeze testing ui-e2e-tests

Also Tested in CI as current PR has UI changes

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[vatsrahul1001]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

@pierrejeambrun updated workflow to run for every UI changes with all browsers

[potiuk]

Nice!

[potiuk]

Until the test suite becomes too long to run. (>15 minutes for instance). I would say we run them in all UI PRs, just to be sure.

We can move that to canary build and only a subset of critical ones if the test suites grows too big.

We can also split them to paralel suites using matrix job, this way the elapsed time will be shorter, we will increase build time spent, but we are still way below the limits that ASF has per-project. We did it successfully for a number of other jobs.

[jscheffl]

@vatsrahul1001 seems canary tests are now broken in Chromium, can you check what is broken (I do not understand the root of the problem :-D need to lern how this works...) --> https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

[vatsrahul1001]

https://github.com/apache/airflow/actions/runs/20110899789/job/57714593194

Looking into this @jscheffl