Just to add comment: a) there was some instability of "celery/boto" hanging tests today that is rather difficult to address - but we worked around it by just removing "special-tests" from pre-requisite of merging b) GitHub today (like literally today!) started to be picky on "too many requests" - I addressed it today for both helm chart and our release tests (we are using bearer-token to authenticate and increase the limit - and we added cache on downloading json schema that was downloaded "per-test" c) in cases like the one mentioned above with intermittent failures - simple "rerun failed jobs" (assuming it will succeed after rerun) - is essentially equivalent of "merge" (unless it fails again which for me is a signal of "DO NOT MERGE") d) we always have the "gitbox" escape hatch - that allows any committer to push the fix directly, bypassing the limits:
This is a simple thing for committers: git add remote gitbox https://gitbox.apache.org/repos/asf/airflow.git git fetch gitbox git commit --amend ("add #PR number") git push gitbox BRANCH_NAME:main (you need to provide your apache id and password) This is a nice escape hatch that we can use as "exceptional workflow" - and it works - I did it quite a few times over the last few days. Not UI controlled, but IMHO exceptional workflow should be - well - exceptional. J. On Tue, Apr 29, 2025 at 8:52 PM Kaxil Naik <kaxiln...@gmail.com> wrote: > Similar experience as Elad, I am in favor of disabling it tbh. For example, > https://github.com/apache/airflow/pull/49727 has a failing test as below > -- > which is not an issue, and test passes locally so I would want to merge it > but I can't. > > FAILED > > helm-tests/tests/helm_tests/airflow_aux/test_basic_helm_chart.py::TestBaseChartTest::test_priority_classes > - requests.exceptions.HTTPError: 429 Client Error: Too Many Requests for > url: > > https://raw.githubusercontent.com/yannh/kubernetes-json-schema/master/v1.29.1-standalone-strict/priorityclass-scheduling-v1.json > > On Tue, 29 Apr 2025 at 18:29, Jarek Potiuk <ja...@potiuk.com> wrote: > > > On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <elad...@apache.org> wrote: > > > > > Thanks for that Jarek! > > > I find the lack of ability to merge PRs fast very limiting but it might > > be > > > just something to get used to. > > > > > > > Indeed. I also see it, but also I got a few manually pushed "must fix > > quickly" to gitbox, and actually I find it really nice - because it is > > still possible, but it require some extra effort and deliberate "ok that > > one really should be pushed to unblock everyone" - as long as we all > > (especially those people that are active in the > > #internal-airfow-ci-cd channel) know how to do it and can fix things > > quickly, this is actually a nice way to make it into "exceptional" > workflow > > - which will push us more in making sure airflow main is really "green" - > > which ultimately is our goal to make it as green as possible all the > time. > > > > What **might help with that** (and also keeping the "enable auto merge" > > might motivate it more to) is to: > > > > * speed up the builds - we MUST prioritise now ARC (K8S self-hosted > > runners) to make our builds simply faster - I started a discussion and a > > small group of people who can work together to complete it after > Hussein's > > POC) > > * speed up the image release - with ARM runners (which we might be able > to > > do independently as recently I think we have hypervisor-enabled ARM > images > > available as public runners as github made it generally available). > > * speed up the doc builds for airflow-site - we (mainly Pavan) are close > to > > complete offloading of the historical release docs to S3 and I hope it > will > > cut down a lot on doc publishing workflows. > > > > J, > > >
