potiuk commented on PR #28096: URL: https://github.com/apache/airflow/pull/28096#issuecomment-1336488664
Actually, the new format did not help that much in terms of UI - even the "new" summary printed in some test types got rather slow in the UI. I've added now additional python scripts that filters out the warnings from the regular stdout - now in CI the warnings will only be printed in the warning files and uploaded as artifacts. I just summarize how many warnings there were. That should be good for both: * those who care about fixing warnings (and fix them) - they can download the warnings and work on them one-by-one * those who care only about failing tests (and do not want to be impacted by the slow UI of GitHub. Later on (when somoene leads/removes all the warnings) we can enable "treat warnings as errors" @ashb @uranusjr @dstandish. However - just to make everyone aware. One note that if we will treat warnings as errors, it will increase frequency of errors to be fixed in the canary runs and I think we should all pay closer attention to them. There are often new warnings generated when new version of a dependency is released - so more often than today, the "main" builds will start failing because of that. This is a consequence of treating warning as errors that we should all be aware of. So when we do it (which is a good thing BTW), we will have to have team of people ready to fix those warnings when they appear. Another option is to push that on the shoulders of those who modify setup.py/setup.cf/provider.yaml files (which is also an option, but might be a bit unexpected for those people that they have to fix unrelated warnings). Unless of course someone will have another idea how to handle those :) I might want to add additional notifications about failed "canary" builds and likely have more volunteers (among the committers I think) that will keep on solving those. Something that we should consider when we switch to "treat warnings as errors". -- 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]
