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 >> > >> >
