Impressive! Thanks Jarek.
On Thu, Sep 5, 2024 at 3:26 PM Jarek Potiuk <ja...@potiuk.com> wrote: > Created an issue in CI/CD project describing what would need to be done to > have CI/CD automation in place for it: > https://github.com/apache/airflow/issues/42031 - should be very easy. > > On Thu, Sep 5, 2024 at 2:46 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > Labels are cool Indeed. > > > > Automated test is not too difficult either. Breeze selective check has > all > > that is needed to figure out the scope of the change in the PR -> > > > https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L183 > > and we can produce the right outputs so that they can be used directly in > > the actions. > > > > It's about 15 lines of code to add :). Might be one of the good first > > issues to tackle by the newly formed CI/CD team. > > > > J. > > > > On Thu, Sep 5, 2024 at 2:13 PM Pierre Jeambrun <pierrejb...@gmail.com> > > wrote: > > > >> Thanks Brent. > >> > >> Yes I like the idea of labels, I believe this will help reviewers know > >> that > >> they have to pay extra attention because specific rules apply to > updating > >> the legacy-ui/api during airflow 3 development. > >> > >> An automated test is even better but might be more effort to develop. > >> > >> On Wed, Sep 4, 2024 at 10:34 PM Buğra Öztürk <ozturkbugr...@gmail.com> > >> wrote: > >> > >> > Thanks for preparing! I think making this distinction between legacy > and > >> > new UI is beneficial for us. It will make it easy to break and change > >> > things. The plan looks great! > >> > > >> > Great point Jarek. Even though it's not critical, I think it would be > >> > beneficial for everyone to see the PR editing the legacy code pieces. > >> > Maybe, we can include a set of labels (like legacy-ui, legacy-api or > >> > some-label...) by using boring-cyborg powers to auto-label certain > >> legacy > >> > code pieces. > >> > > >> > On Wed, Sep 4, 2024 at 4:37 PM Jarek Potiuk <ja...@potiuk.com> wrote: > >> > > >> > > I like the plan in its entirety. > >> > > > >> > > Some technicalities - likely we do not want to automate what is / is > >> not > >> > > allowed - managing it might be difficult, but we could as well add > >> some > >> > > separate non-critical / failing test that will "fail" when the "old" > >> area > >> > > is touched in the PR (but it could be very clearly "just failing > >> because > >> > it > >> > > might not be good to make this.change" - however we could either > set a > >> > > special label on such PRs (to avoid the error) or just merge it with > >> > "red" > >> > > status. > >> > > > >> > > Not critical though. It could also be based on reviews. > >> > > > >> > > J. > >> > > > >> > > On Wed, Sep 4, 2024 at 3:46 PM Brent Bovenzi > >> <br...@astronomer.io.invalid > >> > > > >> > > wrote: > >> > > > >> > > > Hi all, > >> > > > > >> > > > As part of AIPs 38, 79 and 84, Pierre and I have started a new API > >> > based > >> > > on > >> > > > FastAPI and a new UI based purely off of React. The current UI, > rest > >> > API > >> > > > and webserver endpoints will now be considered "legacy" and will > be > >> > > > completely removed by the time Airflow 3.0 is released. But there > >> will > >> > > be a > >> > > > transition time while we get both new projects feature-complete. > >> > > > > >> > > > This means that sometimes we will still have to accept changes to > >> the > >> > > > `airflow/www` javascript files, `airflow/www/views.py` webserver > >> > > endpoints > >> > > > and `airflow/api_connexion` rest API endpoints. But we want to > limit > >> > > > contributions to "legacy" code which will be deleted in a few > short > >> > > > months. Which > >> > > > is specified here in the Airflow docs. > >> > > > <https://github.com/apache/airflow/pull/41903> > >> > > > > >> > > > 1. Bug fixes to cherry pick for 2.10.x and 2.11 > >> > > > 2. The minimum necessary to unblock other Airflow 3.0 feature work > >> > > > 3. Fixes to views and endpoints which we haven't migrated over > yet, > >> but > >> > > can > >> > > > still be ported over to the new UI > >> > > > > >> > > > For example, we will not migrate the legacy UI to use the new REST > >> API. > >> > > > This means that, for a time, we will have duplicate code (ex: two > >> > > different > >> > > > grid_data endpoints). But this reduces the surface area that we > must > >> > > > maintain and allows us to redesign views and endpoints when > >> necessary > >> > > (ex: > >> > > > making the grid_data more efficient and to better support DAG > >> > > versioning). > >> > > > > >> > > > We see three phases to migrating to the UI: > >> > > > 1. New UI has very few features. Show a dismissible banner to > "Check > >> > out > >> > > > the new UI" > >> > > > 2. New UI has most of the core features of Airflow. Make the new > UI > >> the > >> > > > default, and link to the legacy UI as an escape hatch. What is > >> > sufficient > >> > > > for "core features" is to be determined. > >> > > > 3. New UI is fully feature-complete, delete the entire legacy UI > >> > project. > >> > > > > >> > > > Let me know what you all think. I am happy to discuss more on the > >> dev > >> > > call > >> > > > tomorrow. > >> > > > > >> > > > - Brent > >> > > > > >> > > > >> > > >> > > >> > -- > >> > Bugra Ozturk > >> > > >> > > >
