But yes, I also miss the previous "merge because I think it's safe" workflow.
I badly miss it. Personally, It hurts my productivity. But I think the "require status check" to be green is great for "team productivity". Usually when single person is impacted more than team in general, it's worse for the person impacted, but team productivity soars. J. On Tue, Apr 29, 2025 at 11:03 PM Jarek Potiuk <ja...@potiuk.com> wrote: > 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, >> > >> >
