potiuk commented on issue #62500: URL: https://github.com/apache/airflow/issues/62500#issuecomment-4022660222
> One point I’m curious about: should the skill layer stay close to individual Breeze commands, or should it represent higher-level contributor workflows (e.g., static checks, targeted tests, environment transitions) that internally orchestrate multiple Breeze commands depending on context? I think we should aim for something that will be both Human and Agents usable. I would even go as far as to say that we should use the contributing guides as a single source of truth rather than breeze CLI. If anything I would focus on making sure that the workflows described for humans are always updated when we add new breeze command. One thing that is important in those workflows. NOT EVERYTHING should be done with breeze. While breeze is good for repeatable environment and making sure that "works for me" syndrom does not kick in, a lot of the contributor's workflows - such us running tests or pre-commit hooks can be done without breeze. In vast majority of cases this is enough to run tests for example: ```python uv run --project distribution_folder pytest ``` Only when this is not working because some system dependency is missing (mysql librarires for example) we should fall back to breeze way of running tests. Also in case we see discrepancy between the CI and local tests. And I think skills should reflect that. And it's faster and easier to debug as well - as you can run it from the IDE (and agent can also debug it better I guess). So I am wondering if the intermediate layer that should be the "source of truth" should be contributing docs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
