[DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

Hello everyone,

With some initial teething problems we've enabled an "experimental" feature
of "auto-merging" PRs in our repo. It should potentially help with "focus"
of maintainers, because they will not have to come-back to the PRs to merge
it once they enabled auto-merge for them.

It works in the way, that when "required status checks", "reviews" and
"resolved conversations" (the required conditions for "main" protected
branch) are not met, committer can use "Enable auto-merge" on the PR and
when all conditions are met, the PR will get merged automatically.

But after enabling it, it turns out that this has one **serious** drawback.
We currently cannot override the protection from GitHub UI, and it's not
possible to merge PR that did not pass one of the checks (So "Finalize
tests / Summarize warnings" has to complete successfully in order to be
able to merge PR,

This is quite a bit of a blocker. But not entirely, because I've learned (I
did not know it before) that we (committers) already have a way to bypass
ANY protection - by directly pushing code to main branch via gitbox URL
exposed by Apache Infrastructure:

https://gitbox.apache.org/repos/asf

Specifically - you can set this as remote
https://gitbox.apache.org/repos/asf/airflow.git - and push changes directly
to "main" branch. It will bypass any protection. You do not even need to
get a review from another maintainer (yes - I just tested it and it works).
You just need to authenticate with your apache id / password.

That is not great from a security and provenance point of view, but well,
ASF allows it for now (which is something we will have to fix eventually I
think.  It requires using git CLI/local client to push such branches and
there are some small things we have to remember (like manually adding PR #
to the branch we are pushing or not having PR# in the merged commit at all).

Certainly not as convenient as the merge button in PR - but workable if we
want to merge something quickly, regardless of the status (and apparently
regardless of review / approval which is a bummer).

I  left it enabled for a moment - the weekend maximum and maybe beginning
of Monday and would love to hear what you think.

J.

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

Could you show me the email where I start with that? Check
https://lists.apache.org/thread/ofxnb3k5vjqsdlf8wpp7td4n1fjrmmoq again

On Thu, 1 May 2025 at 15:05, Jarek Potiuk <ja...@potiuk.com> wrote:

> Yeah. It more about the communication. "-1" is - literally - by definition
> "negative" when you start your message with "I am strongly -1 on that".
> There is no further explanation given that changes that perception.
>
> On Thu, May 1, 2025 at 11:32 AM Kaxil Naik <ka...@gmail.com> wrote:
>
> > "-1" was backed with rationale discussion and no one has said it was a
> bad
> > idea but you have said it is "negative".
> >
> > On Thu, 1 May 2025 at 14:59, Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > > > That said, I want to push back on the framing of some feedback as
> > > “negative.” I really appreciate the folks who raised concerns, those
> > > perspectives are vital to making the project stronger and more
> inclusive.
> > >
> > > I think what I wanted to say is that I think we should all exercise
> > > empathy. It's super easy to say "-1" but it's harder to say "It's a
> good
> > > idea but ..". Psychological effect of the "-1" is that it "cuts the
> > wings"
> > > of the person who has some idea and wants to follow it through. The
> > > psychological effect of "cool idea, but" is that it - more often than
> > not -
> > > make the person more energised and inspired to look for a better
> > solution.
> > >
> > > And yes I know different people have different communication style, and
> > > there are cultural differences and all that. But I would personally
> love
> > to
> > > see more "yes, but" than "no".
> > >
> > > That's all I want to say..
> > >
> > > J/
> > >
> > >
> > >
> > >
> > >
> > > On Thu, May 1, 2025 at 11:23 AM Kaxil Naik <ka...@gmail.com>
> wrote:
> > >
> > > > Thanks for the energy and initiative here.
> > > >
> > > > That said, I want to push back on the framing of some feedback as
> > > > “negative.” I really appreciate the folks who raised concerns, those
> > > > perspectives are vital to making the project stronger and more
> > inclusive.
> > > >
> > > > Let’s make sure we continue to welcome both enthusiasm and critique.
> As
> > > > the ASF
> > > > Code of Conduct <https://www.apache.org/foundation/policies/conduct>
> > > > reminds us, thoughtful disagreement and diverse viewpoints are not
> only
> > > > expected but encouraged. Referring to concerns as “negative”, even
> > > > unintentionally, can discourage people from speaking up, which we
> want
> > to
> > > > avoid.
> > > >
> > > > We all want what’s best for Airflow, and part of that is making sure
> > > > everyone feels safe to contribute, especially when something doesn’t
> > feel
> > > > right.
> > > >
> > > > >Rather than focusing on the negative side, try to figure out a way
> to
> > > make
> > > > it work :)
> > > >
> > > > Back to the proposal from Jens and you -  Yes that (a comment
> allowing
> > to
> > > > still merge/auto-merge the PR) alleviates my concern.
> > > >
> > > > Regards,
> > > > Kaxil
> > > >
> > > >
> > > >
> > > > On Thu, 1 May 2025 at 12:54, Jarek Potiuk <ja...@potiuk.com> wrote:
> > > >
> > > > > I really like Jens's line of thought. Rather than focusing on the
> > > > negative
> > > > > side, try to figure out a way to make it work :). That's very
> > > inspiring.
> > > > >
> > > > > I think the original slack proposal of Jens was rather brittle, but
> > it
> > > > made
> > > > > me think that we can actually implement what we need rather
> quickly.
> > > > >
> > > > > Following the `Dependabot` style @rebase - we could implement -
> very
> > > > easily
> > > > > - there are ready actions for that and other projects like apache
> > beam
> > > > are
> > > > > using similar workflows - the comment workflow, where maintainer
> who
> > > > wants
> > > > > to merge  (or auto-merge) such "failing" PR would just comment it
> > > > > appropriately.
> > > > >
> > > > > What we really want is to make the "finalize" check succeed, so if
> > the
> > > PR
> > > > > misses the "Finalize" step, a committer would just have to comment
> it
> > > > with
> > > > > "@bypass-finalize` or `@finalize` or similar. And what it would do,
> > it
> > > > > would use Github API to make the "Finalize" check succeed. There is
> > an
> > > > API
> > > > > for that.
> > > > >
> > > > > That has a few nice properties:
> > > > >
> > > > > * it uses the same GitHub UI we use, no need to have an "escape
> > hatch"
> > > > and
> > > > > separate remote
> > > > > * it follows the pattern we already agreed to some time ago and
> > > generally
> > > > > follow -> we are supposed (as maintainers) to explain when we are
> > > merging
> > > > > such failing PR to show that this is a deliberate action - I
> usually
> > > for
> > > > > example always add "fixed already in main" or "Fixed already by
> #..."
> > > > > comment - you really need a comment in this case explaining that it
> > was
> > > > not
> > > > > accidental "merge".
> > > > > * so if we have such workflow, it would "force" maintainer to make
> a
> > > > > deliberate decision "yes I want to merge it despite failing" and
> > make a
> > > > > comment in the PR
> > > > > * it would only set the "finalize" check to succeed, so still you
> > would
> > > > not
> > > > > be able to merge it without having an approval - this would only
> > bypass
> > > > the
> > > > > "finalize" check
> > > > >
> > > > > WDYT? Would that address all concerns with auto-merge ? Does it
> make
> > > > sense
> > > > > and is it "easy enough" to follow? Or are there any other concerns?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Apr 30, 2025 at 10:36 PM Pavankumar Gopidesu <
> > > > > gopidesupavan@gmail.com> wrote:
> > > > >
> > > > > > I am also in line with Jens. The auto-merge feature works well in
> > > > keeping
> > > > > > the CI pipeline green before merging.
> > > > > > However, there are situations where we need to merge changes
> > quickly.
> > > > > > Instead of using an
> > > > > > escape route (which I’m not a fan of, as it carries risks if
> > > something
> > > > > goes
> > > > > > wrong—even though we can revert, it’s still a concern),
> > > > > > we could explore ways to dynamically bypass certain checks when
> > > > necessary
> > > > > > or maybe some help from INFRA?
> > > > > >
> > > > > > Pavan
> > > > > >
> > > > > > On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler
> > > > > <j_scheffler@gmx.de.invalid
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > As there was a call for more opinions. Here I am :-D
> > > > > > >
> > > > > > > I understand both positions. As I like AutoMerge very much I am
> > not
> > > > > > > giving up :-D I'd like to keep it.
> > > > > > >
> > > > > > > I think there is still an option in between. Maybe need to
> draft
> > a
> > > > bit
> > > > > > > of thoughts but I think we could build something still around
> the
> > > > > > > limitations allowing automation.
> > > > > > >
> > > > > > > Added a minor thought to the slack chat. But if community rules
> > > > propose
> > > > > > > to push to devchennel let me know.
> > > > > > >
> > > > > > > Jens
> > > > > > >
> > > > > > > On 30.04.25 11:04, Jarek Potiuk wrote:
> > > > > > > > Yeah, And I would encourage everyone to try it and provide
> > > feedback
> > > > > > while
> > > > > > > > it is enabled.
> > > > > > > >
> > > > > > > > So far we identified a few things (and fix them) that made it
> > > > > > borderline
> > > > > > > > unusable (bug in workflow for UI-only changes, GitHub
> starting
> > to
> > > > > > 429-us
> > > > > > > > with too many requests, and the mysterious "hanging" of the
> > > latest
> > > > > > > > botocore/celery (?) "special tests" -> all that is already
> > > > addressed
> > > > > in
> > > > > > > > main, and those issues should not happen (hopefully), so I'd
> > say
> > > we
> > > > > can
> > > > > > > now
> > > > > > > > "truly" see how it might work.
> > > > > > > >
> > > > > > > > And one comment from my side - indeed, I find it nice
> actually,
> > > but
> > > > > > it's
> > > > > > > > definitely not a "deal breaker"- so if others find it too
> > > > > disruptive, I
> > > > > > > am
> > > > > > > > definitely not going to die on this hill, I just thought it
> > does
> > > > > > improve
> > > > > > > > the workflow in the way that it allows for mostly "fire and
> > > forget"
> > > > > > when
> > > > > > > > you approve the workflow, one thing that it definitely
> improves
> > > is
> > > > > that
> > > > > > > you
> > > > > > > > do not have to remember about coming back to merge a request
> > when
> > > > CI
> > > > > > > > succeeds.
> > > > > > > >
> > > > > > > > J.
> > > > > > > >
> > > > > > > > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <
> > kaxilnaik@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > >> Forgot to note an additional point in Summary: If we find
> > > anything
> > > > > > > blocking
> > > > > > > >> us in that period, we will merge
> > > > > > > >> https://github.com/apache/airflow/pull/50009 to disable
> > > > auto-merge.
> > > > > > > >>
> > > > > > > >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <
> kaxilnaik@gmail.com
> > >
> > > > > wrote:
> > > > > > > >>
> > > > > > > >>> Jarek & I discussed it on Slack in #internal-airflow-ci-cd.
> > > > Summary
> > > > > > > >> below:
> > > > > > > >>> I have a PR to disable it:
> > > > > > > https://github.com/apache/airflow/pull/50009.
> > > > > > > >>> However, given that many countries will be on holiday on
> May
> > 1
> > > > due
> > > > > to
> > > > > > > >>> Labour Day, and some teething issues were fixed yesterday,
> we
> > > > will
> > > > > > let
> > > > > > > it
> > > > > > > >>> run for a few more days so other committers and
> contributors
> > > can
> > > > > get
> > > > > > a
> > > > > > > >>> chance to try it out and share their experience after the
> > > > > > > >> experiment/trial
> > > > > > > >>> is concluded.
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <
> > kaxilnaik@gmail.com>
> > > > > > wrote:
> > > > > > > >>>
> > > > > > > >>>> Whoops yeah.
> > > > > > > >>>>
> > > > > > > >>>>> Yep. Because it did not have all conversations resolved.
> We
> > > > also
> > > > > > have
> > > > > > > >>>> "require resolved conversation" as one of the branch
> > > protection
> > > > > > > >>>> conditions.
> > > > > > > >>>> I resolved the conversation and it got merged
> automatically.
> > > > > > > >>>>
> > > > > > > >>>> Let's adapt it when ready though, I don't see any urgency
> of
> > > > > getting
> > > > > > > >>>> enabling auto-merge or getting it contributed immediately
> to
> > > asf
> > > > > > INFRA
> > > > > > > >> when
> > > > > > > >>>> it isn't critical. It is about priortization
> > > > > > > >>>>
> > > > > > > >>>> I'd say - if that is really bothering us - let's shape the
> > > > feature
> > > > > > > >> rather
> > > > > > > >>>>> than outright reject it.
> > > > > > > >>>>
> > > > > > > >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <
> > jarek@potiuk.com>
> > > > > > wrote:
> > > > > > > >>>>
> > > > > > > >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <
> > > > kaxilnaik@gmail.com>
> > > > > > > >> wrote:
> > > > > > > >>>>>> To the point that the original PR is still not merged
> even
> > > > > after I
> > > > > > > >> had
> > > > > > > >>>>>> re-triggered the failed tests yesterday:
> > > > > > > >>>>>> https://github.com/apache/airflow/pull/49727
> > > > > > > >>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>> Yep. Because it did not have all conversations resolved.
> We
> > > > also
> > > > > > have
> > > > > > > >>>>> "require resolved conversation" as one of the branch
> > > protection
> > > > > > > >>>>> conditions.
> > > > > > > >>>>> I resolved the conversation and it got merged
> > automatically.
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <
> > > kaxilnaik@gmail.com
> > > > >
> > > > > > > >> wrote:
> > > > > > > >>>>>>> The gitbox escape hatch isn't it though -- if we are to
> > > allow
> > > > > > that
> > > > > > > >>>>> why
> > > > > > > >>>>>> not
> > > > > > > >>>>>>> just allow people to merge it directly from github that
> > to
> > > go
> > > > > via
> > > > > > > >> an
> > > > > > > >>>>>>> "escape hatch".
> > > > > > > >>>>> Generally speaking GitHub has this option. Currently
> > "admins"
> > > > > have
> > > > > > a
> > > > > > > >>>>> possibility of overriding branch protection (via UI). And
> > it
> > > > > would
> > > > > > be
> > > > > > > >>>>> possible - if INFRA will allow it - to possibly add an
> > > > .asf.yaml
> > > > > > > >> feature
> > > > > > > >>>>> to
> > > > > > > >>>>> also allow branch protection override for all committers
> > or a
> > > > > > subset
> > > > > > > of
> > > > > > > >>>>> the
> > > > > > > >>>>> committers (PMC Members ? ). This is more of a limitation
> > of
> > > > the
> > > > > > > >> current
> > > > > > > >>>>> implementation of permissions than a missing feature. If
> we
> > > all
> > > > > > feel
> > > > > > > >> that
> > > > > > > >>>>> the gitbox escape hatch is not enough, we can likely even
> > > > > > contribute
> > > > > > > >>>>> such a
> > > > > > > >>>>> feature to .asf.yaml - if INFRA will be ok with the
> option.
> > > > It's
> > > > > > very
> > > > > > > >>>>> easy
> > > > > > > >>>>> to contribute to - INFRA made it possible, we have a new
> > > > > framework:
> > > > > > > >>>>> https://github.com/apache/infrastructure-asfyaml - we
> can
> > > even
> > > > > > > >> implement
> > > > > > > >>>>> "airflow-only" .asf.yaml feature, that will not be
> > initially
> > > > > > > available
> > > > > > > >> to
> > > > > > > >>>>> other ASF projects and later we can promote it to be
> > > available
> > > > to
> > > > > > > >>>>> everyone.
> > > > > > > >>>>>
> > > > > > > >>>>> I'd say - if that is really bothering us - let's shape
> the
> > > > > feature
> > > > > > > >> rather
> > > > > > > >>>>> than outright reject it.
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>>> I am -1 on this auto-merge feature
> > > > > > > >>>>>>>
> > > > > > > >>>>> Understood :). But let's give it a bit more time as well
> > and
> > > > > maybe
> > > > > > > >>>>> improve
> > > > > > > >>>>> it (see above) - unless we really feel we are blocked
> now -
> > > > then
> > > > > it
> > > > > > > >>>>> should
> > > > > > > >>>>> be as easy as merging an .asf.yaml change to disable it.
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <
> > > > kaxilnaik@gmail.com>
> > > > > > > >>>>> wrote:
> > > > > > > >>>>>>>> That’s not a single person, it impacts the committers
> > and
> > > > the
> > > > > PR
> > > > > > > >>>>> author
> > > > > > > >>>>>>>> involved too. I don’t see how team productivity soars
> > > here.
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <
> > > > jarek@potiuk.com>
> > > > > > > >>>>> wrote:
> > > > > > > >>>>>>>>> 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 <
> > > > > > jarek@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 <
> > > > > > > >> kaxilnaik@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 <
> > > > > jarek@potiuk.com
> > > > > > >
> > > > > > > >>>>>> wrote:
> > > > > > > >>>>>>>>>>>> On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <
> > > > > > > >>>>> eladkal@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,
> > > > > > > >>>>>>>>>>>>
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > > > > > > For additional commands, e-mail: dev-help@airflow.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

Yeah. It more about the communication. "-1" is - literally - by definition
"negative" when you start your message with "I am strongly -1 on that".
There is no further explanation given that changes that perception.

On Thu, May 1, 2025 at 11:32 AM Kaxil Naik <ka...@gmail.com> wrote:

> "-1" was backed with rationale discussion and no one has said it was a bad
> idea but you have said it is "negative".
>
> On Thu, 1 May 2025 at 14:59, Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > > That said, I want to push back on the framing of some feedback as
> > “negative.” I really appreciate the folks who raised concerns, those
> > perspectives are vital to making the project stronger and more inclusive.
> >
> > I think what I wanted to say is that I think we should all exercise
> > empathy. It's super easy to say "-1" but it's harder to say "It's a good
> > idea but ..". Psychological effect of the "-1" is that it "cuts the
> wings"
> > of the person who has some idea and wants to follow it through. The
> > psychological effect of "cool idea, but" is that it - more often than
> not -
> > make the person more energised and inspired to look for a better
> solution.
> >
> > And yes I know different people have different communication style, and
> > there are cultural differences and all that. But I would personally love
> to
> > see more "yes, but" than "no".
> >
> > That's all I want to say..
> >
> > J/
> >
> >
> >
> >
> >
> > On Thu, May 1, 2025 at 11:23 AM Kaxil Naik <ka...@gmail.com> wrote:
> >
> > > Thanks for the energy and initiative here.
> > >
> > > That said, I want to push back on the framing of some feedback as
> > > “negative.” I really appreciate the folks who raised concerns, those
> > > perspectives are vital to making the project stronger and more
> inclusive.
> > >
> > > Let’s make sure we continue to welcome both enthusiasm and critique. As
> > > the ASF
> > > Code of Conduct <https://www.apache.org/foundation/policies/conduct>
> > > reminds us, thoughtful disagreement and diverse viewpoints are not only
> > > expected but encouraged. Referring to concerns as “negative”, even
> > > unintentionally, can discourage people from speaking up, which we want
> to
> > > avoid.
> > >
> > > We all want what’s best for Airflow, and part of that is making sure
> > > everyone feels safe to contribute, especially when something doesn’t
> feel
> > > right.
> > >
> > > >Rather than focusing on the negative side, try to figure out a way to
> > make
> > > it work :)
> > >
> > > Back to the proposal from Jens and you -  Yes that (a comment allowing
> to
> > > still merge/auto-merge the PR) alleviates my concern.
> > >
> > > Regards,
> > > Kaxil
> > >
> > >
> > >
> > > On Thu, 1 May 2025 at 12:54, Jarek Potiuk <ja...@potiuk.com> wrote:
> > >
> > > > I really like Jens's line of thought. Rather than focusing on the
> > > negative
> > > > side, try to figure out a way to make it work :). That's very
> > inspiring.
> > > >
> > > > I think the original slack proposal of Jens was rather brittle, but
> it
> > > made
> > > > me think that we can actually implement what we need rather quickly.
> > > >
> > > > Following the `Dependabot` style @rebase - we could implement - very
> > > easily
> > > > - there are ready actions for that and other projects like apache
> beam
> > > are
> > > > using similar workflows - the comment workflow, where maintainer who
> > > wants
> > > > to merge  (or auto-merge) such "failing" PR would just comment it
> > > > appropriately.
> > > >
> > > > What we really want is to make the "finalize" check succeed, so if
> the
> > PR
> > > > misses the "Finalize" step, a committer would just have to comment it
> > > with
> > > > "@bypass-finalize` or `@finalize` or similar. And what it would do,
> it
> > > > would use Github API to make the "Finalize" check succeed. There is
> an
> > > API
> > > > for that.
> > > >
> > > > That has a few nice properties:
> > > >
> > > > * it uses the same GitHub UI we use, no need to have an "escape
> hatch"
> > > and
> > > > separate remote
> > > > * it follows the pattern we already agreed to some time ago and
> > generally
> > > > follow -> we are supposed (as maintainers) to explain when we are
> > merging
> > > > such failing PR to show that this is a deliberate action - I usually
> > for
> > > > example always add "fixed already in main" or "Fixed already by #..."
> > > > comment - you really need a comment in this case explaining that it
> was
> > > not
> > > > accidental "merge".
> > > > * so if we have such workflow, it would "force" maintainer to make a
> > > > deliberate decision "yes I want to merge it despite failing" and
> make a
> > > > comment in the PR
> > > > * it would only set the "finalize" check to succeed, so still you
> would
> > > not
> > > > be able to merge it without having an approval - this would only
> bypass
> > > the
> > > > "finalize" check
> > > >
> > > > WDYT? Would that address all concerns with auto-merge ? Does it make
> > > sense
> > > > and is it "easy enough" to follow? Or are there any other concerns?
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Apr 30, 2025 at 10:36 PM Pavankumar Gopidesu <
> > > > gopidesupavan@gmail.com> wrote:
> > > >
> > > > > I am also in line with Jens. The auto-merge feature works well in
> > > keeping
> > > > > the CI pipeline green before merging.
> > > > > However, there are situations where we need to merge changes
> quickly.
> > > > > Instead of using an
> > > > > escape route (which I’m not a fan of, as it carries risks if
> > something
> > > > goes
> > > > > wrong—even though we can revert, it’s still a concern),
> > > > > we could explore ways to dynamically bypass certain checks when
> > > necessary
> > > > > or maybe some help from INFRA?
> > > > >
> > > > > Pavan
> > > > >
> > > > > On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler
> > > > <j_scheffler@gmx.de.invalid
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > As there was a call for more opinions. Here I am :-D
> > > > > >
> > > > > > I understand both positions. As I like AutoMerge very much I am
> not
> > > > > > giving up :-D I'd like to keep it.
> > > > > >
> > > > > > I think there is still an option in between. Maybe need to draft
> a
> > > bit
> > > > > > of thoughts but I think we could build something still around the
> > > > > > limitations allowing automation.
> > > > > >
> > > > > > Added a minor thought to the slack chat. But if community rules
> > > propose
> > > > > > to push to devchennel let me know.
> > > > > >
> > > > > > Jens
> > > > > >
> > > > > > On 30.04.25 11:04, Jarek Potiuk wrote:
> > > > > > > Yeah, And I would encourage everyone to try it and provide
> > feedback
> > > > > while
> > > > > > > it is enabled.
> > > > > > >
> > > > > > > So far we identified a few things (and fix them) that made it
> > > > > borderline
> > > > > > > unusable (bug in workflow for UI-only changes, GitHub starting
> to
> > > > > 429-us
> > > > > > > with too many requests, and the mysterious "hanging" of the
> > latest
> > > > > > > botocore/celery (?) "special tests" -> all that is already
> > > addressed
> > > > in
> > > > > > > main, and those issues should not happen (hopefully), so I'd
> say
> > we
> > > > can
> > > > > > now
> > > > > > > "truly" see how it might work.
> > > > > > >
> > > > > > > And one comment from my side - indeed, I find it nice actually,
> > but
> > > > > it's
> > > > > > > definitely not a "deal breaker"- so if others find it too
> > > > disruptive, I
> > > > > > am
> > > > > > > definitely not going to die on this hill, I just thought it
> does
> > > > > improve
> > > > > > > the workflow in the way that it allows for mostly "fire and
> > forget"
> > > > > when
> > > > > > > you approve the workflow, one thing that it definitely improves
> > is
> > > > that
> > > > > > you
> > > > > > > do not have to remember about coming back to merge a request
> when
> > > CI
> > > > > > > succeeds.
> > > > > > >
> > > > > > > J.
> > > > > > >
> > > > > > > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <
> kaxilnaik@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > >> Forgot to note an additional point in Summary: If we find
> > anything
> > > > > > blocking
> > > > > > >> us in that period, we will merge
> > > > > > >> https://github.com/apache/airflow/pull/50009 to disable
> > > auto-merge.
> > > > > > >>
> > > > > > >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <kaxilnaik@gmail.com
> >
> > > > wrote:
> > > > > > >>
> > > > > > >>> Jarek & I discussed it on Slack in #internal-airflow-ci-cd.
> > > Summary
> > > > > > >> below:
> > > > > > >>> I have a PR to disable it:
> > > > > > https://github.com/apache/airflow/pull/50009.
> > > > > > >>> However, given that many countries will be on holiday on May
> 1
> > > due
> > > > to
> > > > > > >>> Labour Day, and some teething issues were fixed yesterday, we
> > > will
> > > > > let
> > > > > > it
> > > > > > >>> run for a few more days so other committers and contributors
> > can
> > > > get
> > > > > a
> > > > > > >>> chance to try it out and share their experience after the
> > > > > > >> experiment/trial
> > > > > > >>> is concluded.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <
> kaxilnaik@gmail.com>
> > > > > wrote:
> > > > > > >>>
> > > > > > >>>> Whoops yeah.
> > > > > > >>>>
> > > > > > >>>>> Yep. Because it did not have all conversations resolved. We
> > > also
> > > > > have
> > > > > > >>>> "require resolved conversation" as one of the branch
> > protection
> > > > > > >>>> conditions.
> > > > > > >>>> I resolved the conversation and it got merged automatically.
> > > > > > >>>>
> > > > > > >>>> Let's adapt it when ready though, I don't see any urgency of
> > > > getting
> > > > > > >>>> enabling auto-merge or getting it contributed immediately to
> > asf
> > > > > INFRA
> > > > > > >> when
> > > > > > >>>> it isn't critical. It is about priortization
> > > > > > >>>>
> > > > > > >>>> I'd say - if that is really bothering us - let's shape the
> > > feature
> > > > > > >> rather
> > > > > > >>>>> than outright reject it.
> > > > > > >>>>
> > > > > > >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <
> jarek@potiuk.com>
> > > > > wrote:
> > > > > > >>>>
> > > > > > >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <
> > > kaxilnaik@gmail.com>
> > > > > > >> wrote:
> > > > > > >>>>>> To the point that the original PR is still not merged even
> > > > after I
> > > > > > >> had
> > > > > > >>>>>> re-triggered the failed tests yesterday:
> > > > > > >>>>>> https://github.com/apache/airflow/pull/49727
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>> Yep. Because it did not have all conversations resolved. We
> > > also
> > > > > have
> > > > > > >>>>> "require resolved conversation" as one of the branch
> > protection
> > > > > > >>>>> conditions.
> > > > > > >>>>> I resolved the conversation and it got merged
> automatically.
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <
> > kaxilnaik@gmail.com
> > > >
> > > > > > >> wrote:
> > > > > > >>>>>>> The gitbox escape hatch isn't it though -- if we are to
> > allow
> > > > > that
> > > > > > >>>>> why
> > > > > > >>>>>> not
> > > > > > >>>>>>> just allow people to merge it directly from github that
> to
> > go
> > > > via
> > > > > > >> an
> > > > > > >>>>>>> "escape hatch".
> > > > > > >>>>> Generally speaking GitHub has this option. Currently
> "admins"
> > > > have
> > > > > a
> > > > > > >>>>> possibility of overriding branch protection (via UI). And
> it
> > > > would
> > > > > be
> > > > > > >>>>> possible - if INFRA will allow it - to possibly add an
> > > .asf.yaml
> > > > > > >> feature
> > > > > > >>>>> to
> > > > > > >>>>> also allow branch protection override for all committers
> or a
> > > > > subset
> > > > > > of
> > > > > > >>>>> the
> > > > > > >>>>> committers (PMC Members ? ). This is more of a limitation
> of
> > > the
> > > > > > >> current
> > > > > > >>>>> implementation of permissions than a missing feature. If we
> > all
> > > > > feel
> > > > > > >> that
> > > > > > >>>>> the gitbox escape hatch is not enough, we can likely even
> > > > > contribute
> > > > > > >>>>> such a
> > > > > > >>>>> feature to .asf.yaml - if INFRA will be ok with the option.
> > > It's
> > > > > very
> > > > > > >>>>> easy
> > > > > > >>>>> to contribute to - INFRA made it possible, we have a new
> > > > framework:
> > > > > > >>>>> https://github.com/apache/infrastructure-asfyaml - we can
> > even
> > > > > > >> implement
> > > > > > >>>>> "airflow-only" .asf.yaml feature, that will not be
> initially
> > > > > > available
> > > > > > >> to
> > > > > > >>>>> other ASF projects and later we can promote it to be
> > available
> > > to
> > > > > > >>>>> everyone.
> > > > > > >>>>>
> > > > > > >>>>> I'd say - if that is really bothering us - let's shape the
> > > > feature
> > > > > > >> rather
> > > > > > >>>>> than outright reject it.
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>>> I am -1 on this auto-merge feature
> > > > > > >>>>>>>
> > > > > > >>>>> Understood :). But let's give it a bit more time as well
> and
> > > > maybe
> > > > > > >>>>> improve
> > > > > > >>>>> it (see above) - unless we really feel we are blocked now -
> > > then
> > > > it
> > > > > > >>>>> should
> > > > > > >>>>> be as easy as merging an .asf.yaml change to disable it.
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <
> > > kaxilnaik@gmail.com>
> > > > > > >>>>> wrote:
> > > > > > >>>>>>>> That’s not a single person, it impacts the committers
> and
> > > the
> > > > PR
> > > > > > >>>>> author
> > > > > > >>>>>>>> involved too. I don’t see how team productivity soars
> > here.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <
> > > jarek@potiuk.com>
> > > > > > >>>>> wrote:
> > > > > > >>>>>>>>> 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 <
> > > > > jarek@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 <
> > > > > > >> kaxilnaik@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 <
> > > > jarek@potiuk.com
> > > > > >
> > > > > > >>>>>> wrote:
> > > > > > >>>>>>>>>>>> On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <
> > > > > > >>>>> eladkal@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,
> > > > > > >>>>>>>>>>>>
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > > > > > For additional commands, e-mail: dev-help@airflow.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

FYI, I changed my mind about auto-merging.

In the last couple of days I merged many PRs quickly when they were still
running because I "knew" they were ok. It would be huge impact if I had to
wait for all of them to succeed. I think now that the marginal improvement
in "focus" when reviewing the PRs is not worth it.

On Thu, May 1, 2025 at 11:38 AM Kaxil Naik <ka...@gmail.com> wrote:

> That's what I was saying. But welcoming discussion or feedback and then
> terming it negative is a no-go, Jarek.
>
>
>
> On Thu, 1 May 2025 at 15:07, Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > I propose - let's not be defensive or offensive, but try to hear each
> other
> > and improve things in the future :).
> >
> > On Thu, May 1, 2025 at 11:35 AM Kaxil Naik <ka...@gmail.com> wrote:
> >
> > > >But I would personally love to see more "yes, but" than "no".
> > >
> > > Saying "would love to hear what you think" in the original message
> > followed
> > > by terming "negative" is not the way to collaborate.
> > >
> > > On Thu, 1 May 2025 at 15:01, Kaxil Naik <ka...@gmail.com> wrote:
> > >
> > > > "-1" was backed with rationale discussion and no one has said it was
> a
> > > bad
> > > > idea but you have said it is "negative".
> > > >
> > > > On Thu, 1 May 2025 at 14:59, Jarek Potiuk <ja...@potiuk.com> wrote:
> > > >
> > > >> > That said, I want to push back on the framing of some feedback as
> > > >> “negative.” I really appreciate the folks who raised concerns, those
> > > >> perspectives are vital to making the project stronger and more
> > > inclusive.
> > > >>
> > > >> I think what I wanted to say is that I think we should all exercise
> > > >> empathy. It's super easy to say "-1" but it's harder to say "It's a
> > good
> > > >> idea but ..". Psychological effect of the "-1" is that it "cuts the
> > > wings"
> > > >> of the person who has some idea and wants to follow it through. The
> > > >> psychological effect of "cool idea, but" is that it - more often
> than
> > > not
> > > >> -
> > > >> make the person more energised and inspired to look for a better
> > > solution.
> > > >>
> > > >> And yes I know different people have different communication style,
> > and
> > > >> there are cultural differences and all that. But I would personally
> > love
> > > >> to
> > > >> see more "yes, but" than "no".
> > > >>
> > > >> That's all I want to say..
> > > >>
> > > >> J/
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Thu, May 1, 2025 at 11:23 AM Kaxil Naik <ka...@gmail.com>
> > wrote:
> > > >>
> > > >> > Thanks for the energy and initiative here.
> > > >> >
> > > >> > That said, I want to push back on the framing of some feedback as
> > > >> > “negative.” I really appreciate the folks who raised concerns,
> those
> > > >> > perspectives are vital to making the project stronger and more
> > > >> inclusive.
> > > >> >
> > > >> > Let’s make sure we continue to welcome both enthusiasm and
> critique.
> > > As
> > > >> > the ASF
> > > >> > Code of Conduct <
> https://www.apache.org/foundation/policies/conduct
> > >
> > > >> > reminds us, thoughtful disagreement and diverse viewpoints are not
> > > only
> > > >> > expected but encouraged. Referring to concerns as “negative”, even
> > > >> > unintentionally, can discourage people from speaking up, which we
> > want
> > > >> to
> > > >> > avoid.
> > > >> >
> > > >> > We all want what’s best for Airflow, and part of that is making
> sure
> > > >> > everyone feels safe to contribute, especially when something
> doesn’t
> > > >> feel
> > > >> > right.
> > > >> >
> > > >> > >Rather than focusing on the negative side, try to figure out a
> way
> > to
> > > >> make
> > > >> > it work :)
> > > >> >
> > > >> > Back to the proposal from Jens and you -  Yes that (a comment
> > allowing
> > > >> to
> > > >> > still merge/auto-merge the PR) alleviates my concern.
> > > >> >
> > > >> > Regards,
> > > >> > Kaxil
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Thu, 1 May 2025 at 12:54, Jarek Potiuk <ja...@potiuk.com>
> wrote:
> > > >> >
> > > >> > > I really like Jens's line of thought. Rather than focusing on
> the
> > > >> > negative
> > > >> > > side, try to figure out a way to make it work :). That's very
> > > >> inspiring.
> > > >> > >
> > > >> > > I think the original slack proposal of Jens was rather brittle,
> > but
> > > it
> > > >> > made
> > > >> > > me think that we can actually implement what we need rather
> > quickly.
> > > >> > >
> > > >> > > Following the `Dependabot` style @rebase - we could implement -
> > very
> > > >> > easily
> > > >> > > - there are ready actions for that and other projects like
> apache
> > > beam
> > > >> > are
> > > >> > > using similar workflows - the comment workflow, where maintainer
> > who
> > > >> > wants
> > > >> > > to merge  (or auto-merge) such "failing" PR would just comment
> it
> > > >> > > appropriately.
> > > >> > >
> > > >> > > What we really want is to make the "finalize" check succeed, so
> if
> > > >> the PR
> > > >> > > misses the "Finalize" step, a committer would just have to
> comment
> > > it
> > > >> > with
> > > >> > > "@bypass-finalize` or `@finalize` or similar. And what it would
> > do,
> > > it
> > > >> > > would use Github API to make the "Finalize" check succeed. There
> > is
> > > an
> > > >> > API
> > > >> > > for that.
> > > >> > >
> > > >> > > That has a few nice properties:
> > > >> > >
> > > >> > > * it uses the same GitHub UI we use, no need to have an "escape
> > > hatch"
> > > >> > and
> > > >> > > separate remote
> > > >> > > * it follows the pattern we already agreed to some time ago and
> > > >> generally
> > > >> > > follow -> we are supposed (as maintainers) to explain when we
> are
> > > >> merging
> > > >> > > such failing PR to show that this is a deliberate action - I
> > usually
> > > >> for
> > > >> > > example always add "fixed already in main" or "Fixed already by
> > > #..."
> > > >> > > comment - you really need a comment in this case explaining that
> > it
> > > >> was
> > > >> > not
> > > >> > > accidental "merge".
> > > >> > > * so if we have such workflow, it would "force" maintainer to
> > make a
> > > >> > > deliberate decision "yes I want to merge it despite failing" and
> > > make
> > > >> a
> > > >> > > comment in the PR
> > > >> > > * it would only set the "finalize" check to succeed, so still
> you
> > > >> would
> > > >> > not
> > > >> > > be able to merge it without having an approval - this would only
> > > >> bypass
> > > >> > the
> > > >> > > "finalize" check
> > > >> > >
> > > >> > > WDYT? Would that address all concerns with auto-merge ? Does it
> > make
> > > >> > sense
> > > >> > > and is it "easy enough" to follow? Or are there any other
> > concerns?
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > On Wed, Apr 30, 2025 at 10:36 PM Pavankumar Gopidesu <
> > > >> > > gopidesupavan@gmail.com> wrote:
> > > >> > >
> > > >> > > > I am also in line with Jens. The auto-merge feature works well
> > in
> > > >> > keeping
> > > >> > > > the CI pipeline green before merging.
> > > >> > > > However, there are situations where we need to merge changes
> > > >> quickly.
> > > >> > > > Instead of using an
> > > >> > > > escape route (which I’m not a fan of, as it carries risks if
> > > >> something
> > > >> > > goes
> > > >> > > > wrong—even though we can revert, it’s still a concern),
> > > >> > > > we could explore ways to dynamically bypass certain checks
> when
> > > >> > necessary
> > > >> > > > or maybe some help from INFRA?
> > > >> > > >
> > > >> > > > Pavan
> > > >> > > >
> > > >> > > > On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler
> > > >> > > <j_scheffler@gmx.de.invalid
> > > >> > > > >
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > > > As there was a call for more opinions. Here I am :-D
> > > >> > > > >
> > > >> > > > > I understand both positions. As I like AutoMerge very much I
> > am
> > > >> not
> > > >> > > > > giving up :-D I'd like to keep it.
> > > >> > > > >
> > > >> > > > > I think there is still an option in between. Maybe need to
> > > draft a
> > > >> > bit
> > > >> > > > > of thoughts but I think we could build something still
> around
> > > the
> > > >> > > > > limitations allowing automation.
> > > >> > > > >
> > > >> > > > > Added a minor thought to the slack chat. But if community
> > rules
> > > >> > propose
> > > >> > > > > to push to devchennel let me know.
> > > >> > > > >
> > > >> > > > > Jens
> > > >> > > > >
> > > >> > > > > On 30.04.25 11:04, Jarek Potiuk wrote:
> > > >> > > > > > Yeah, And I would encourage everyone to try it and provide
> > > >> feedback
> > > >> > > > while
> > > >> > > > > > it is enabled.
> > > >> > > > > >
> > > >> > > > > > So far we identified a few things (and fix them) that made
> > it
> > > >> > > > borderline
> > > >> > > > > > unusable (bug in workflow for UI-only changes, GitHub
> > starting
> > > >> to
> > > >> > > > 429-us
> > > >> > > > > > with too many requests, and the mysterious "hanging" of
> the
> > > >> latest
> > > >> > > > > > botocore/celery (?) "special tests" -> all that is already
> > > >> > addressed
> > > >> > > in
> > > >> > > > > > main, and those issues should not happen (hopefully), so
> I'd
> > > >> say we
> > > >> > > can
> > > >> > > > > now
> > > >> > > > > > "truly" see how it might work.
> > > >> > > > > >
> > > >> > > > > > And one comment from my side - indeed, I find it nice
> > > actually,
> > > >> but
> > > >> > > > it's
> > > >> > > > > > definitely not a "deal breaker"- so if others find it too
> > > >> > > disruptive, I
> > > >> > > > > am
> > > >> > > > > > definitely not going to die on this hill, I just thought
> it
> > > does
> > > >> > > > improve
> > > >> > > > > > the workflow in the way that it allows for mostly "fire
> and
> > > >> forget"
> > > >> > > > when
> > > >> > > > > > you approve the workflow, one thing that it definitely
> > > improves
> > > >> is
> > > >> > > that
> > > >> > > > > you
> > > >> > > > > > do not have to remember about coming back to merge a
> request
> > > >> when
> > > >> > CI
> > > >> > > > > > succeeds.
> > > >> > > > > >
> > > >> > > > > > J.
> > > >> > > > > >
> > > >> > > > > > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <
> > > >> kaxilnaik@gmail.com>
> > > >> > > > wrote:
> > > >> > > > > >
> > > >> > > > > >> Forgot to note an additional point in Summary: If we find
> > > >> anything
> > > >> > > > > blocking
> > > >> > > > > >> us in that period, we will merge
> > > >> > > > > >> https://github.com/apache/airflow/pull/50009 to disable
> > > >> > auto-merge.
> > > >> > > > > >>
> > > >> > > > > >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <
> > > kaxilnaik@gmail.com>
> > > >> > > wrote:
> > > >> > > > > >>
> > > >> > > > > >>> Jarek & I discussed it on Slack in
> > #internal-airflow-ci-cd.
> > > >> > Summary
> > > >> > > > > >> below:
> > > >> > > > > >>> I have a PR to disable it:
> > > >> > > > > https://github.com/apache/airflow/pull/50009.
> > > >> > > > > >>> However, given that many countries will be on holiday on
> > > May 1
> > > >> > due
> > > >> > > to
> > > >> > > > > >>> Labour Day, and some teething issues were fixed
> yesterday,
> > > we
> > > >> > will
> > > >> > > > let
> > > >> > > > > it
> > > >> > > > > >>> run for a few more days so other committers and
> > contributors
> > > >> can
> > > >> > > get
> > > >> > > > a
> > > >> > > > > >>> chance to try it out and share their experience after
> the
> > > >> > > > > >> experiment/trial
> > > >> > > > > >>> is concluded.
> > > >> > > > > >>>
> > > >> > > > > >>>
> > > >> > > > > >>>
> > > >> > > > > >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <
> > > kaxilnaik@gmail.com
> > > >> >
> > > >> > > > wrote:
> > > >> > > > > >>>
> > > >> > > > > >>>> Whoops yeah.
> > > >> > > > > >>>>
> > > >> > > > > >>>>> Yep. Because it did not have all conversations
> resolved.
> > > We
> > > >> > also
> > > >> > > > have
> > > >> > > > > >>>> "require resolved conversation" as one of the branch
> > > >> protection
> > > >> > > > > >>>> conditions.
> > > >> > > > > >>>> I resolved the conversation and it got merged
> > > automatically.
> > > >> > > > > >>>>
> > > >> > > > > >>>> Let's adapt it when ready though, I don't see any
> urgency
> > > of
> > > >> > > getting
> > > >> > > > > >>>> enabling auto-merge or getting it contributed
> immediately
> > > to
> > > >> asf
> > > >> > > > INFRA
> > > >> > > > > >> when
> > > >> > > > > >>>> it isn't critical. It is about priortization
> > > >> > > > > >>>>
> > > >> > > > > >>>> I'd say - if that is really bothering us - let's shape
> > the
> > > >> > feature
> > > >> > > > > >> rather
> > > >> > > > > >>>>> than outright reject it.
> > > >> > > > > >>>>
> > > >> > > > > >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <
> > > jarek@potiuk.com
> > > >> >
> > > >> > > > wrote:
> > > >> > > > > >>>>
> > > >> > > > > >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <
> > > >> > kaxilnaik@gmail.com>
> > > >> > > > > >> wrote:
> > > >> > > > > >>>>>> To the point that the original PR is still not merged
> > > even
> > > >> > > after I
> > > >> > > > > >> had
> > > >> > > > > >>>>>> re-triggered the failed tests yesterday:
> > > >> > > > > >>>>>> https://github.com/apache/airflow/pull/49727
> > > >> > > > > >>>>>>
> > > >> > > > > >>>>>>
> > > >> > > > > >>>>> Yep. Because it did not have all conversations
> resolved.
> > > We
> > > >> > also
> > > >> > > > have
> > > >> > > > > >>>>> "require resolved conversation" as one of the branch
> > > >> protection
> > > >> > > > > >>>>> conditions.
> > > >> > > > > >>>>> I resolved the conversation and it got merged
> > > automatically.
> > > >> > > > > >>>>>
> > > >> > > > > >>>>>
> > > >> > > > > >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <
> > > >> kaxilnaik@gmail.com
> > > >> > >
> > > >> > > > > >> wrote:
> > > >> > > > > >>>>>>> The gitbox escape hatch isn't it though -- if we are
> > to
> > > >> allow
> > > >> > > > that
> > > >> > > > > >>>>> why
> > > >> > > > > >>>>>> not
> > > >> > > > > >>>>>>> just allow people to merge it directly from github
> > that
> > > >> to go
> > > >> > > via
> > > >> > > > > >> an
> > > >> > > > > >>>>>>> "escape hatch".
> > > >> > > > > >>>>> Generally speaking GitHub has this option. Currently
> > > >> "admins"
> > > >> > > have
> > > >> > > > a
> > > >> > > > > >>>>> possibility of overriding branch protection (via UI).
> > And
> > > it
> > > >> > > would
> > > >> > > > be
> > > >> > > > > >>>>> possible - if INFRA will allow it - to possibly add an
> > > >> > .asf.yaml
> > > >> > > > > >> feature
> > > >> > > > > >>>>> to
> > > >> > > > > >>>>> also allow branch protection override for all
> committers
> > > or
> > > >> a
> > > >> > > > subset
> > > >> > > > > of
> > > >> > > > > >>>>> the
> > > >> > > > > >>>>> committers (PMC Members ? ). This is more of a
> > limitation
> > > of
> > > >> > the
> > > >> > > > > >> current
> > > >> > > > > >>>>> implementation of permissions than a missing feature.
> If
> > > we
> > > >> all
> > > >> > > > feel
> > > >> > > > > >> that
> > > >> > > > > >>>>> the gitbox escape hatch is not enough, we can likely
> > even
> > > >> > > > contribute
> > > >> > > > > >>>>> such a
> > > >> > > > > >>>>> feature to .asf.yaml - if INFRA will be ok with the
> > > option.
> > > >> > It's
> > > >> > > > very
> > > >> > > > > >>>>> easy
> > > >> > > > > >>>>> to contribute to - INFRA made it possible, we have a
> new
> > > >> > > framework:
> > > >> > > > > >>>>> https://github.com/apache/infrastructure-asfyaml - we
> > can
> > > >> even
> > > >> > > > > >> implement
> > > >> > > > > >>>>> "airflow-only" .asf.yaml feature, that will not be
> > > initially
> > > >> > > > > available
> > > >> > > > > >> to
> > > >> > > > > >>>>> other ASF projects and later we can promote it to be
> > > >> available
> > > >> > to
> > > >> > > > > >>>>> everyone.
> > > >> > > > > >>>>>
> > > >> > > > > >>>>> I'd say - if that is really bothering us - let's shape
> > the
> > > >> > > feature
> > > >> > > > > >> rather
> > > >> > > > > >>>>> than outright reject it.
> > > >> > > > > >>>>>
> > > >> > > > > >>>>>
> > > >> > > > > >>>>>>> I am -1 on this auto-merge feature
> > > >> > > > > >>>>>>>
> > > >> > > > > >>>>> Understood :). But let's give it a bit more time as
> well
> > > and
> > > >> > > maybe
> > > >> > > > > >>>>> improve
> > > >> > > > > >>>>> it (see above) - unless we really feel we are blocked
> > now
> > > -
> > > >> > then
> > > >> > > it
> > > >> > > > > >>>>> should
> > > >> > > > > >>>>> be as easy as merging an .asf.yaml change to disable
> it.
> > > >> > > > > >>>>>
> > > >> > > > > >>>>>
> > > >> > > > > >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <
> > > >> > kaxilnaik@gmail.com>
> > > >> > > > > >>>>> wrote:
> > > >> > > > > >>>>>>>> That’s not a single person, it impacts the
> committers
> > > and
> > > >> > the
> > > >> > > PR
> > > >> > > > > >>>>> author
> > > >> > > > > >>>>>>>> involved too. I don’t see how team productivity
> soars
> > > >> here.
> > > >> > > > > >>>>>>>>
> > > >> > > > > >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <
> > > >> > jarek@potiuk.com>
> > > >> > > > > >>>>> wrote:
> > > >> > > > > >>>>>>>>> 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 <
> > > >> > > > jarek@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 <
> > > >> > > > > >> kaxilnaik@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 <
> > > >> > > jarek@potiuk.com
> > > >> > > > >
> > > >> > > > > >>>>>> wrote:
> > > >> > > > > >>>>>>>>>>>> On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <
> > > >> > > > > >>>>> eladkal@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,
> > > >> > > > > >>>>>>>>>>>>
> > > >> > > > >
> > > >> > > > >
> > > >>
> ---------------------------------------------------------------------
> > > >> > > > > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > > >> > > > > For additional commands, e-mail:
> dev-help@airflow.apache.org
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

That's what I was saying. But welcoming discussion or feedback and then
terming it negative is a no-go, Jarek.



On Thu, 1 May 2025 at 15:07, Jarek Potiuk <ja...@potiuk.com> wrote:

> I propose - let's not be defensive or offensive, but try to hear each other
> and improve things in the future :).
>
> On Thu, May 1, 2025 at 11:35 AM Kaxil Naik <ka...@gmail.com> wrote:
>
> > >But I would personally love to see more "yes, but" than "no".
> >
> > Saying "would love to hear what you think" in the original message
> followed
> > by terming "negative" is not the way to collaborate.
> >
> > On Thu, 1 May 2025 at 15:01, Kaxil Naik <ka...@gmail.com> wrote:
> >
> > > "-1" was backed with rationale discussion and no one has said it was a
> > bad
> > > idea but you have said it is "negative".
> > >
> > > On Thu, 1 May 2025 at 14:59, Jarek Potiuk <ja...@potiuk.com> wrote:
> > >
> > >> > That said, I want to push back on the framing of some feedback as
> > >> “negative.” I really appreciate the folks who raised concerns, those
> > >> perspectives are vital to making the project stronger and more
> > inclusive.
> > >>
> > >> I think what I wanted to say is that I think we should all exercise
> > >> empathy. It's super easy to say "-1" but it's harder to say "It's a
> good
> > >> idea but ..". Psychological effect of the "-1" is that it "cuts the
> > wings"
> > >> of the person who has some idea and wants to follow it through. The
> > >> psychological effect of "cool idea, but" is that it - more often than
> > not
> > >> -
> > >> make the person more energised and inspired to look for a better
> > solution.
> > >>
> > >> And yes I know different people have different communication style,
> and
> > >> there are cultural differences and all that. But I would personally
> love
> > >> to
> > >> see more "yes, but" than "no".
> > >>
> > >> That's all I want to say..
> > >>
> > >> J/
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Thu, May 1, 2025 at 11:23 AM Kaxil Naik <ka...@gmail.com>
> wrote:
> > >>
> > >> > Thanks for the energy and initiative here.
> > >> >
> > >> > That said, I want to push back on the framing of some feedback as
> > >> > “negative.” I really appreciate the folks who raised concerns, those
> > >> > perspectives are vital to making the project stronger and more
> > >> inclusive.
> > >> >
> > >> > Let’s make sure we continue to welcome both enthusiasm and critique.
> > As
> > >> > the ASF
> > >> > Code of Conduct <https://www.apache.org/foundation/policies/conduct
> >
> > >> > reminds us, thoughtful disagreement and diverse viewpoints are not
> > only
> > >> > expected but encouraged. Referring to concerns as “negative”, even
> > >> > unintentionally, can discourage people from speaking up, which we
> want
> > >> to
> > >> > avoid.
> > >> >
> > >> > We all want what’s best for Airflow, and part of that is making sure
> > >> > everyone feels safe to contribute, especially when something doesn’t
> > >> feel
> > >> > right.
> > >> >
> > >> > >Rather than focusing on the negative side, try to figure out a way
> to
> > >> make
> > >> > it work :)
> > >> >
> > >> > Back to the proposal from Jens and you -  Yes that (a comment
> allowing
> > >> to
> > >> > still merge/auto-merge the PR) alleviates my concern.
> > >> >
> > >> > Regards,
> > >> > Kaxil
> > >> >
> > >> >
> > >> >
> > >> > On Thu, 1 May 2025 at 12:54, Jarek Potiuk <ja...@potiuk.com> wrote:
> > >> >
> > >> > > I really like Jens's line of thought. Rather than focusing on the
> > >> > negative
> > >> > > side, try to figure out a way to make it work :). That's very
> > >> inspiring.
> > >> > >
> > >> > > I think the original slack proposal of Jens was rather brittle,
> but
> > it
> > >> > made
> > >> > > me think that we can actually implement what we need rather
> quickly.
> > >> > >
> > >> > > Following the `Dependabot` style @rebase - we could implement -
> very
> > >> > easily
> > >> > > - there are ready actions for that and other projects like apache
> > beam
> > >> > are
> > >> > > using similar workflows - the comment workflow, where maintainer
> who
> > >> > wants
> > >> > > to merge  (or auto-merge) such "failing" PR would just comment it
> > >> > > appropriately.
> > >> > >
> > >> > > What we really want is to make the "finalize" check succeed, so if
> > >> the PR
> > >> > > misses the "Finalize" step, a committer would just have to comment
> > it
> > >> > with
> > >> > > "@bypass-finalize` or `@finalize` or similar. And what it would
> do,
> > it
> > >> > > would use Github API to make the "Finalize" check succeed. There
> is
> > an
> > >> > API
> > >> > > for that.
> > >> > >
> > >> > > That has a few nice properties:
> > >> > >
> > >> > > * it uses the same GitHub UI we use, no need to have an "escape
> > hatch"
> > >> > and
> > >> > > separate remote
> > >> > > * it follows the pattern we already agreed to some time ago and
> > >> generally
> > >> > > follow -> we are supposed (as maintainers) to explain when we are
> > >> merging
> > >> > > such failing PR to show that this is a deliberate action - I
> usually
> > >> for
> > >> > > example always add "fixed already in main" or "Fixed already by
> > #..."
> > >> > > comment - you really need a comment in this case explaining that
> it
> > >> was
> > >> > not
> > >> > > accidental "merge".
> > >> > > * so if we have such workflow, it would "force" maintainer to
> make a
> > >> > > deliberate decision "yes I want to merge it despite failing" and
> > make
> > >> a
> > >> > > comment in the PR
> > >> > > * it would only set the "finalize" check to succeed, so still you
> > >> would
> > >> > not
> > >> > > be able to merge it without having an approval - this would only
> > >> bypass
> > >> > the
> > >> > > "finalize" check
> > >> > >
> > >> > > WDYT? Would that address all concerns with auto-merge ? Does it
> make
> > >> > sense
> > >> > > and is it "easy enough" to follow? Or are there any other
> concerns?
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Wed, Apr 30, 2025 at 10:36 PM Pavankumar Gopidesu <
> > >> > > gopidesupavan@gmail.com> wrote:
> > >> > >
> > >> > > > I am also in line with Jens. The auto-merge feature works well
> in
> > >> > keeping
> > >> > > > the CI pipeline green before merging.
> > >> > > > However, there are situations where we need to merge changes
> > >> quickly.
> > >> > > > Instead of using an
> > >> > > > escape route (which I’m not a fan of, as it carries risks if
> > >> something
> > >> > > goes
> > >> > > > wrong—even though we can revert, it’s still a concern),
> > >> > > > we could explore ways to dynamically bypass certain checks when
> > >> > necessary
> > >> > > > or maybe some help from INFRA?
> > >> > > >
> > >> > > > Pavan
> > >> > > >
> > >> > > > On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler
> > >> > > <j_scheffler@gmx.de.invalid
> > >> > > > >
> > >> > > > wrote:
> > >> > > >
> > >> > > > > As there was a call for more opinions. Here I am :-D
> > >> > > > >
> > >> > > > > I understand both positions. As I like AutoMerge very much I
> am
> > >> not
> > >> > > > > giving up :-D I'd like to keep it.
> > >> > > > >
> > >> > > > > I think there is still an option in between. Maybe need to
> > draft a
> > >> > bit
> > >> > > > > of thoughts but I think we could build something still around
> > the
> > >> > > > > limitations allowing automation.
> > >> > > > >
> > >> > > > > Added a minor thought to the slack chat. But if community
> rules
> > >> > propose
> > >> > > > > to push to devchennel let me know.
> > >> > > > >
> > >> > > > > Jens
> > >> > > > >
> > >> > > > > On 30.04.25 11:04, Jarek Potiuk wrote:
> > >> > > > > > Yeah, And I would encourage everyone to try it and provide
> > >> feedback
> > >> > > > while
> > >> > > > > > it is enabled.
> > >> > > > > >
> > >> > > > > > So far we identified a few things (and fix them) that made
> it
> > >> > > > borderline
> > >> > > > > > unusable (bug in workflow for UI-only changes, GitHub
> starting
> > >> to
> > >> > > > 429-us
> > >> > > > > > with too many requests, and the mysterious "hanging" of the
> > >> latest
> > >> > > > > > botocore/celery (?) "special tests" -> all that is already
> > >> > addressed
> > >> > > in
> > >> > > > > > main, and those issues should not happen (hopefully), so I'd
> > >> say we
> > >> > > can
> > >> > > > > now
> > >> > > > > > "truly" see how it might work.
> > >> > > > > >
> > >> > > > > > And one comment from my side - indeed, I find it nice
> > actually,
> > >> but
> > >> > > > it's
> > >> > > > > > definitely not a "deal breaker"- so if others find it too
> > >> > > disruptive, I
> > >> > > > > am
> > >> > > > > > definitely not going to die on this hill, I just thought it
> > does
> > >> > > > improve
> > >> > > > > > the workflow in the way that it allows for mostly "fire and
> > >> forget"
> > >> > > > when
> > >> > > > > > you approve the workflow, one thing that it definitely
> > improves
> > >> is
> > >> > > that
> > >> > > > > you
> > >> > > > > > do not have to remember about coming back to merge a request
> > >> when
> > >> > CI
> > >> > > > > > succeeds.
> > >> > > > > >
> > >> > > > > > J.
> > >> > > > > >
> > >> > > > > > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <
> > >> kaxilnaik@gmail.com>
> > >> > > > wrote:
> > >> > > > > >
> > >> > > > > >> Forgot to note an additional point in Summary: If we find
> > >> anything
> > >> > > > > blocking
> > >> > > > > >> us in that period, we will merge
> > >> > > > > >> https://github.com/apache/airflow/pull/50009 to disable
> > >> > auto-merge.
> > >> > > > > >>
> > >> > > > > >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <
> > kaxilnaik@gmail.com>
> > >> > > wrote:
> > >> > > > > >>
> > >> > > > > >>> Jarek & I discussed it on Slack in
> #internal-airflow-ci-cd.
> > >> > Summary
> > >> > > > > >> below:
> > >> > > > > >>> I have a PR to disable it:
> > >> > > > > https://github.com/apache/airflow/pull/50009.
> > >> > > > > >>> However, given that many countries will be on holiday on
> > May 1
> > >> > due
> > >> > > to
> > >> > > > > >>> Labour Day, and some teething issues were fixed yesterday,
> > we
> > >> > will
> > >> > > > let
> > >> > > > > it
> > >> > > > > >>> run for a few more days so other committers and
> contributors
> > >> can
> > >> > > get
> > >> > > > a
> > >> > > > > >>> chance to try it out and share their experience after the
> > >> > > > > >> experiment/trial
> > >> > > > > >>> is concluded.
> > >> > > > > >>>
> > >> > > > > >>>
> > >> > > > > >>>
> > >> > > > > >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <
> > kaxilnaik@gmail.com
> > >> >
> > >> > > > wrote:
> > >> > > > > >>>
> > >> > > > > >>>> Whoops yeah.
> > >> > > > > >>>>
> > >> > > > > >>>>> Yep. Because it did not have all conversations resolved.
> > We
> > >> > also
> > >> > > > have
> > >> > > > > >>>> "require resolved conversation" as one of the branch
> > >> protection
> > >> > > > > >>>> conditions.
> > >> > > > > >>>> I resolved the conversation and it got merged
> > automatically.
> > >> > > > > >>>>
> > >> > > > > >>>> Let's adapt it when ready though, I don't see any urgency
> > of
> > >> > > getting
> > >> > > > > >>>> enabling auto-merge or getting it contributed immediately
> > to
> > >> asf
> > >> > > > INFRA
> > >> > > > > >> when
> > >> > > > > >>>> it isn't critical. It is about priortization
> > >> > > > > >>>>
> > >> > > > > >>>> I'd say - if that is really bothering us - let's shape
> the
> > >> > feature
> > >> > > > > >> rather
> > >> > > > > >>>>> than outright reject it.
> > >> > > > > >>>>
> > >> > > > > >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <
> > jarek@potiuk.com
> > >> >
> > >> > > > wrote:
> > >> > > > > >>>>
> > >> > > > > >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <
> > >> > kaxilnaik@gmail.com>
> > >> > > > > >> wrote:
> > >> > > > > >>>>>> To the point that the original PR is still not merged
> > even
> > >> > > after I
> > >> > > > > >> had
> > >> > > > > >>>>>> re-triggered the failed tests yesterday:
> > >> > > > > >>>>>> https://github.com/apache/airflow/pull/49727
> > >> > > > > >>>>>>
> > >> > > > > >>>>>>
> > >> > > > > >>>>> Yep. Because it did not have all conversations resolved.
> > We
> > >> > also
> > >> > > > have
> > >> > > > > >>>>> "require resolved conversation" as one of the branch
> > >> protection
> > >> > > > > >>>>> conditions.
> > >> > > > > >>>>> I resolved the conversation and it got merged
> > automatically.
> > >> > > > > >>>>>
> > >> > > > > >>>>>
> > >> > > > > >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <
> > >> kaxilnaik@gmail.com
> > >> > >
> > >> > > > > >> wrote:
> > >> > > > > >>>>>>> The gitbox escape hatch isn't it though -- if we are
> to
> > >> allow
> > >> > > > that
> > >> > > > > >>>>> why
> > >> > > > > >>>>>> not
> > >> > > > > >>>>>>> just allow people to merge it directly from github
> that
> > >> to go
> > >> > > via
> > >> > > > > >> an
> > >> > > > > >>>>>>> "escape hatch".
> > >> > > > > >>>>> Generally speaking GitHub has this option. Currently
> > >> "admins"
> > >> > > have
> > >> > > > a
> > >> > > > > >>>>> possibility of overriding branch protection (via UI).
> And
> > it
> > >> > > would
> > >> > > > be
> > >> > > > > >>>>> possible - if INFRA will allow it - to possibly add an
> > >> > .asf.yaml
> > >> > > > > >> feature
> > >> > > > > >>>>> to
> > >> > > > > >>>>> also allow branch protection override for all committers
> > or
> > >> a
> > >> > > > subset
> > >> > > > > of
> > >> > > > > >>>>> the
> > >> > > > > >>>>> committers (PMC Members ? ). This is more of a
> limitation
> > of
> > >> > the
> > >> > > > > >> current
> > >> > > > > >>>>> implementation of permissions than a missing feature. If
> > we
> > >> all
> > >> > > > feel
> > >> > > > > >> that
> > >> > > > > >>>>> the gitbox escape hatch is not enough, we can likely
> even
> > >> > > > contribute
> > >> > > > > >>>>> such a
> > >> > > > > >>>>> feature to .asf.yaml - if INFRA will be ok with the
> > option.
> > >> > It's
> > >> > > > very
> > >> > > > > >>>>> easy
> > >> > > > > >>>>> to contribute to - INFRA made it possible, we have a new
> > >> > > framework:
> > >> > > > > >>>>> https://github.com/apache/infrastructure-asfyaml - we
> can
> > >> even
> > >> > > > > >> implement
> > >> > > > > >>>>> "airflow-only" .asf.yaml feature, that will not be
> > initially
> > >> > > > > available
> > >> > > > > >> to
> > >> > > > > >>>>> other ASF projects and later we can promote it to be
> > >> available
> > >> > to
> > >> > > > > >>>>> everyone.
> > >> > > > > >>>>>
> > >> > > > > >>>>> I'd say - if that is really bothering us - let's shape
> the
> > >> > > feature
> > >> > > > > >> rather
> > >> > > > > >>>>> than outright reject it.
> > >> > > > > >>>>>
> > >> > > > > >>>>>
> > >> > > > > >>>>>>> I am -1 on this auto-merge feature
> > >> > > > > >>>>>>>
> > >> > > > > >>>>> Understood :). But let's give it a bit more time as well
> > and
> > >> > > maybe
> > >> > > > > >>>>> improve
> > >> > > > > >>>>> it (see above) - unless we really feel we are blocked
> now
> > -
> > >> > then
> > >> > > it
> > >> > > > > >>>>> should
> > >> > > > > >>>>> be as easy as merging an .asf.yaml change to disable it.
> > >> > > > > >>>>>
> > >> > > > > >>>>>
> > >> > > > > >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <
> > >> > kaxilnaik@gmail.com>
> > >> > > > > >>>>> wrote:
> > >> > > > > >>>>>>>> That’s not a single person, it impacts the committers
> > and
> > >> > the
> > >> > > PR
> > >> > > > > >>>>> author
> > >> > > > > >>>>>>>> involved too. I don’t see how team productivity soars
> > >> here.
> > >> > > > > >>>>>>>>
> > >> > > > > >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <
> > >> > jarek@potiuk.com>
> > >> > > > > >>>>> wrote:
> > >> > > > > >>>>>>>>> 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 <
> > >> > > > jarek@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 <
> > >> > > > > >> kaxilnaik@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 <
> > >> > > jarek@potiuk.com
> > >> > > > >
> > >> > > > > >>>>>> wrote:
> > >> > > > > >>>>>>>>>>>> On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <
> > >> > > > > >>>>> eladkal@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,
> > >> > > > > >>>>>>>>>>>>
> > >> > > > >
> > >> > > > >
> > >> ---------------------------------------------------------------------
> > >> > > > > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > >> > > > > For additional commands, e-mail: dev-help@airflow.apache.org
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

I propose - let's not be defensive or offensive, but try to hear each other
and improve things in the future :).

On Thu, May 1, 2025 at 11:35 AM Kaxil Naik <ka...@gmail.com> wrote:

> >But I would personally love to see more "yes, but" than "no".
>
> Saying "would love to hear what you think" in the original message followed
> by terming "negative" is not the way to collaborate.
>
> On Thu, 1 May 2025 at 15:01, Kaxil Naik <ka...@gmail.com> wrote:
>
> > "-1" was backed with rationale discussion and no one has said it was a
> bad
> > idea but you have said it is "negative".
> >
> > On Thu, 1 May 2025 at 14:59, Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> >> > That said, I want to push back on the framing of some feedback as
> >> “negative.” I really appreciate the folks who raised concerns, those
> >> perspectives are vital to making the project stronger and more
> inclusive.
> >>
> >> I think what I wanted to say is that I think we should all exercise
> >> empathy. It's super easy to say "-1" but it's harder to say "It's a good
> >> idea but ..". Psychological effect of the "-1" is that it "cuts the
> wings"
> >> of the person who has some idea and wants to follow it through. The
> >> psychological effect of "cool idea, but" is that it - more often than
> not
> >> -
> >> make the person more energised and inspired to look for a better
> solution.
> >>
> >> And yes I know different people have different communication style, and
> >> there are cultural differences and all that. But I would personally love
> >> to
> >> see more "yes, but" than "no".
> >>
> >> That's all I want to say..
> >>
> >> J/
> >>
> >>
> >>
> >>
> >>
> >> On Thu, May 1, 2025 at 11:23 AM Kaxil Naik <ka...@gmail.com> wrote:
> >>
> >> > Thanks for the energy and initiative here.
> >> >
> >> > That said, I want to push back on the framing of some feedback as
> >> > “negative.” I really appreciate the folks who raised concerns, those
> >> > perspectives are vital to making the project stronger and more
> >> inclusive.
> >> >
> >> > Let’s make sure we continue to welcome both enthusiasm and critique.
> As
> >> > the ASF
> >> > Code of Conduct <https://www.apache.org/foundation/policies/conduct>
> >> > reminds us, thoughtful disagreement and diverse viewpoints are not
> only
> >> > expected but encouraged. Referring to concerns as “negative”, even
> >> > unintentionally, can discourage people from speaking up, which we want
> >> to
> >> > avoid.
> >> >
> >> > We all want what’s best for Airflow, and part of that is making sure
> >> > everyone feels safe to contribute, especially when something doesn’t
> >> feel
> >> > right.
> >> >
> >> > >Rather than focusing on the negative side, try to figure out a way to
> >> make
> >> > it work :)
> >> >
> >> > Back to the proposal from Jens and you -  Yes that (a comment allowing
> >> to
> >> > still merge/auto-merge the PR) alleviates my concern.
> >> >
> >> > Regards,
> >> > Kaxil
> >> >
> >> >
> >> >
> >> > On Thu, 1 May 2025 at 12:54, Jarek Potiuk <ja...@potiuk.com> wrote:
> >> >
> >> > > I really like Jens's line of thought. Rather than focusing on the
> >> > negative
> >> > > side, try to figure out a way to make it work :). That's very
> >> inspiring.
> >> > >
> >> > > I think the original slack proposal of Jens was rather brittle, but
> it
> >> > made
> >> > > me think that we can actually implement what we need rather quickly.
> >> > >
> >> > > Following the `Dependabot` style @rebase - we could implement - very
> >> > easily
> >> > > - there are ready actions for that and other projects like apache
> beam
> >> > are
> >> > > using similar workflows - the comment workflow, where maintainer who
> >> > wants
> >> > > to merge  (or auto-merge) such "failing" PR would just comment it
> >> > > appropriately.
> >> > >
> >> > > What we really want is to make the "finalize" check succeed, so if
> >> the PR
> >> > > misses the "Finalize" step, a committer would just have to comment
> it
> >> > with
> >> > > "@bypass-finalize` or `@finalize` or similar. And what it would do,
> it
> >> > > would use Github API to make the "Finalize" check succeed. There is
> an
> >> > API
> >> > > for that.
> >> > >
> >> > > That has a few nice properties:
> >> > >
> >> > > * it uses the same GitHub UI we use, no need to have an "escape
> hatch"
> >> > and
> >> > > separate remote
> >> > > * it follows the pattern we already agreed to some time ago and
> >> generally
> >> > > follow -> we are supposed (as maintainers) to explain when we are
> >> merging
> >> > > such failing PR to show that this is a deliberate action - I usually
> >> for
> >> > > example always add "fixed already in main" or "Fixed already by
> #..."
> >> > > comment - you really need a comment in this case explaining that it
> >> was
> >> > not
> >> > > accidental "merge".
> >> > > * so if we have such workflow, it would "force" maintainer to make a
> >> > > deliberate decision "yes I want to merge it despite failing" and
> make
> >> a
> >> > > comment in the PR
> >> > > * it would only set the "finalize" check to succeed, so still you
> >> would
> >> > not
> >> > > be able to merge it without having an approval - this would only
> >> bypass
> >> > the
> >> > > "finalize" check
> >> > >
> >> > > WDYT? Would that address all concerns with auto-merge ? Does it make
> >> > sense
> >> > > and is it "easy enough" to follow? Or are there any other concerns?
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Wed, Apr 30, 2025 at 10:36 PM Pavankumar Gopidesu <
> >> > > gopidesupavan@gmail.com> wrote:
> >> > >
> >> > > > I am also in line with Jens. The auto-merge feature works well in
> >> > keeping
> >> > > > the CI pipeline green before merging.
> >> > > > However, there are situations where we need to merge changes
> >> quickly.
> >> > > > Instead of using an
> >> > > > escape route (which I’m not a fan of, as it carries risks if
> >> something
> >> > > goes
> >> > > > wrong—even though we can revert, it’s still a concern),
> >> > > > we could explore ways to dynamically bypass certain checks when
> >> > necessary
> >> > > > or maybe some help from INFRA?
> >> > > >
> >> > > > Pavan
> >> > > >
> >> > > > On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler
> >> > > <j_scheffler@gmx.de.invalid
> >> > > > >
> >> > > > wrote:
> >> > > >
> >> > > > > As there was a call for more opinions. Here I am :-D
> >> > > > >
> >> > > > > I understand both positions. As I like AutoMerge very much I am
> >> not
> >> > > > > giving up :-D I'd like to keep it.
> >> > > > >
> >> > > > > I think there is still an option in between. Maybe need to
> draft a
> >> > bit
> >> > > > > of thoughts but I think we could build something still around
> the
> >> > > > > limitations allowing automation.
> >> > > > >
> >> > > > > Added a minor thought to the slack chat. But if community rules
> >> > propose
> >> > > > > to push to devchennel let me know.
> >> > > > >
> >> > > > > Jens
> >> > > > >
> >> > > > > On 30.04.25 11:04, Jarek Potiuk wrote:
> >> > > > > > Yeah, And I would encourage everyone to try it and provide
> >> feedback
> >> > > > while
> >> > > > > > it is enabled.
> >> > > > > >
> >> > > > > > So far we identified a few things (and fix them) that made it
> >> > > > borderline
> >> > > > > > unusable (bug in workflow for UI-only changes, GitHub starting
> >> to
> >> > > > 429-us
> >> > > > > > with too many requests, and the mysterious "hanging" of the
> >> latest
> >> > > > > > botocore/celery (?) "special tests" -> all that is already
> >> > addressed
> >> > > in
> >> > > > > > main, and those issues should not happen (hopefully), so I'd
> >> say we
> >> > > can
> >> > > > > now
> >> > > > > > "truly" see how it might work.
> >> > > > > >
> >> > > > > > And one comment from my side - indeed, I find it nice
> actually,
> >> but
> >> > > > it's
> >> > > > > > definitely not a "deal breaker"- so if others find it too
> >> > > disruptive, I
> >> > > > > am
> >> > > > > > definitely not going to die on this hill, I just thought it
> does
> >> > > > improve
> >> > > > > > the workflow in the way that it allows for mostly "fire and
> >> forget"
> >> > > > when
> >> > > > > > you approve the workflow, one thing that it definitely
> improves
> >> is
> >> > > that
> >> > > > > you
> >> > > > > > do not have to remember about coming back to merge a request
> >> when
> >> > CI
> >> > > > > > succeeds.
> >> > > > > >
> >> > > > > > J.
> >> > > > > >
> >> > > > > > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <
> >> kaxilnaik@gmail.com>
> >> > > > wrote:
> >> > > > > >
> >> > > > > >> Forgot to note an additional point in Summary: If we find
> >> anything
> >> > > > > blocking
> >> > > > > >> us in that period, we will merge
> >> > > > > >> https://github.com/apache/airflow/pull/50009 to disable
> >> > auto-merge.
> >> > > > > >>
> >> > > > > >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <
> kaxilnaik@gmail.com>
> >> > > wrote:
> >> > > > > >>
> >> > > > > >>> Jarek & I discussed it on Slack in #internal-airflow-ci-cd.
> >> > Summary
> >> > > > > >> below:
> >> > > > > >>> I have a PR to disable it:
> >> > > > > https://github.com/apache/airflow/pull/50009.
> >> > > > > >>> However, given that many countries will be on holiday on
> May 1
> >> > due
> >> > > to
> >> > > > > >>> Labour Day, and some teething issues were fixed yesterday,
> we
> >> > will
> >> > > > let
> >> > > > > it
> >> > > > > >>> run for a few more days so other committers and contributors
> >> can
> >> > > get
> >> > > > a
> >> > > > > >>> chance to try it out and share their experience after the
> >> > > > > >> experiment/trial
> >> > > > > >>> is concluded.
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>>
> >> > > > > >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <
> kaxilnaik@gmail.com
> >> >
> >> > > > wrote:
> >> > > > > >>>
> >> > > > > >>>> Whoops yeah.
> >> > > > > >>>>
> >> > > > > >>>>> Yep. Because it did not have all conversations resolved.
> We
> >> > also
> >> > > > have
> >> > > > > >>>> "require resolved conversation" as one of the branch
> >> protection
> >> > > > > >>>> conditions.
> >> > > > > >>>> I resolved the conversation and it got merged
> automatically.
> >> > > > > >>>>
> >> > > > > >>>> Let's adapt it when ready though, I don't see any urgency
> of
> >> > > getting
> >> > > > > >>>> enabling auto-merge or getting it contributed immediately
> to
> >> asf
> >> > > > INFRA
> >> > > > > >> when
> >> > > > > >>>> it isn't critical. It is about priortization
> >> > > > > >>>>
> >> > > > > >>>> I'd say - if that is really bothering us - let's shape the
> >> > feature
> >> > > > > >> rather
> >> > > > > >>>>> than outright reject it.
> >> > > > > >>>>
> >> > > > > >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <
> jarek@potiuk.com
> >> >
> >> > > > wrote:
> >> > > > > >>>>
> >> > > > > >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <
> >> > kaxilnaik@gmail.com>
> >> > > > > >> wrote:
> >> > > > > >>>>>> To the point that the original PR is still not merged
> even
> >> > > after I
> >> > > > > >> had
> >> > > > > >>>>>> re-triggered the failed tests yesterday:
> >> > > > > >>>>>> https://github.com/apache/airflow/pull/49727
> >> > > > > >>>>>>
> >> > > > > >>>>>>
> >> > > > > >>>>> Yep. Because it did not have all conversations resolved.
> We
> >> > also
> >> > > > have
> >> > > > > >>>>> "require resolved conversation" as one of the branch
> >> protection
> >> > > > > >>>>> conditions.
> >> > > > > >>>>> I resolved the conversation and it got merged
> automatically.
> >> > > > > >>>>>
> >> > > > > >>>>>
> >> > > > > >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <
> >> kaxilnaik@gmail.com
> >> > >
> >> > > > > >> wrote:
> >> > > > > >>>>>>> The gitbox escape hatch isn't it though -- if we are to
> >> allow
> >> > > > that
> >> > > > > >>>>> why
> >> > > > > >>>>>> not
> >> > > > > >>>>>>> just allow people to merge it directly from github that
> >> to go
> >> > > via
> >> > > > > >> an
> >> > > > > >>>>>>> "escape hatch".
> >> > > > > >>>>> Generally speaking GitHub has this option. Currently
> >> "admins"
> >> > > have
> >> > > > a
> >> > > > > >>>>> possibility of overriding branch protection (via UI). And
> it
> >> > > would
> >> > > > be
> >> > > > > >>>>> possible - if INFRA will allow it - to possibly add an
> >> > .asf.yaml
> >> > > > > >> feature
> >> > > > > >>>>> to
> >> > > > > >>>>> also allow branch protection override for all committers
> or
> >> a
> >> > > > subset
> >> > > > > of
> >> > > > > >>>>> the
> >> > > > > >>>>> committers (PMC Members ? ). This is more of a limitation
> of
> >> > the
> >> > > > > >> current
> >> > > > > >>>>> implementation of permissions than a missing feature. If
> we
> >> all
> >> > > > feel
> >> > > > > >> that
> >> > > > > >>>>> the gitbox escape hatch is not enough, we can likely even
> >> > > > contribute
> >> > > > > >>>>> such a
> >> > > > > >>>>> feature to .asf.yaml - if INFRA will be ok with the
> option.
> >> > It's
> >> > > > very
> >> > > > > >>>>> easy
> >> > > > > >>>>> to contribute to - INFRA made it possible, we have a new
> >> > > framework:
> >> > > > > >>>>> https://github.com/apache/infrastructure-asfyaml - we can
> >> even
> >> > > > > >> implement
> >> > > > > >>>>> "airflow-only" .asf.yaml feature, that will not be
> initially
> >> > > > > available
> >> > > > > >> to
> >> > > > > >>>>> other ASF projects and later we can promote it to be
> >> available
> >> > to
> >> > > > > >>>>> everyone.
> >> > > > > >>>>>
> >> > > > > >>>>> I'd say - if that is really bothering us - let's shape the
> >> > > feature
> >> > > > > >> rather
> >> > > > > >>>>> than outright reject it.
> >> > > > > >>>>>
> >> > > > > >>>>>
> >> > > > > >>>>>>> I am -1 on this auto-merge feature
> >> > > > > >>>>>>>
> >> > > > > >>>>> Understood :). But let's give it a bit more time as well
> and
> >> > > maybe
> >> > > > > >>>>> improve
> >> > > > > >>>>> it (see above) - unless we really feel we are blocked now
> -
> >> > then
> >> > > it
> >> > > > > >>>>> should
> >> > > > > >>>>> be as easy as merging an .asf.yaml change to disable it.
> >> > > > > >>>>>
> >> > > > > >>>>>
> >> > > > > >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <
> >> > kaxilnaik@gmail.com>
> >> > > > > >>>>> wrote:
> >> > > > > >>>>>>>> That’s not a single person, it impacts the committers
> and
> >> > the
> >> > > PR
> >> > > > > >>>>> author
> >> > > > > >>>>>>>> involved too. I don’t see how team productivity soars
> >> here.
> >> > > > > >>>>>>>>
> >> > > > > >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <
> >> > jarek@potiuk.com>
> >> > > > > >>>>> wrote:
> >> > > > > >>>>>>>>> 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 <
> >> > > > jarek@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 <
> >> > > > > >> kaxilnaik@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 <
> >> > > jarek@potiuk.com
> >> > > > >
> >> > > > > >>>>>> wrote:
> >> > > > > >>>>>>>>>>>> On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <
> >> > > > > >>>>> eladkal@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,
> >> > > > > >>>>>>>>>>>>
> >> > > > >
> >> > > > >
> >> ---------------------------------------------------------------------
> >> > > > > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> >> > > > > For additional commands, e-mail: dev-help@airflow.apache.org
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

>But I would personally love to see more "yes, but" than "no".

Saying "would love to hear what you think" in the original message followed
by terming "negative" is not the way to collaborate.

On Thu, 1 May 2025 at 15:01, Kaxil Naik <ka...@gmail.com> wrote:

> "-1" was backed with rationale discussion and no one has said it was a bad
> idea but you have said it is "negative".
>
> On Thu, 1 May 2025 at 14:59, Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> > That said, I want to push back on the framing of some feedback as
>> “negative.” I really appreciate the folks who raised concerns, those
>> perspectives are vital to making the project stronger and more inclusive.
>>
>> I think what I wanted to say is that I think we should all exercise
>> empathy. It's super easy to say "-1" but it's harder to say "It's a good
>> idea but ..". Psychological effect of the "-1" is that it "cuts the wings"
>> of the person who has some idea and wants to follow it through. The
>> psychological effect of "cool idea, but" is that it - more often than not
>> -
>> make the person more energised and inspired to look for a better solution.
>>
>> And yes I know different people have different communication style, and
>> there are cultural differences and all that. But I would personally love
>> to
>> see more "yes, but" than "no".
>>
>> That's all I want to say..
>>
>> J/
>>
>>
>>
>>
>>
>> On Thu, May 1, 2025 at 11:23 AM Kaxil Naik <ka...@gmail.com> wrote:
>>
>> > Thanks for the energy and initiative here.
>> >
>> > That said, I want to push back on the framing of some feedback as
>> > “negative.” I really appreciate the folks who raised concerns, those
>> > perspectives are vital to making the project stronger and more
>> inclusive.
>> >
>> > Let’s make sure we continue to welcome both enthusiasm and critique. As
>> > the ASF
>> > Code of Conduct <https://www.apache.org/foundation/policies/conduct>
>> > reminds us, thoughtful disagreement and diverse viewpoints are not only
>> > expected but encouraged. Referring to concerns as “negative”, even
>> > unintentionally, can discourage people from speaking up, which we want
>> to
>> > avoid.
>> >
>> > We all want what’s best for Airflow, and part of that is making sure
>> > everyone feels safe to contribute, especially when something doesn’t
>> feel
>> > right.
>> >
>> > >Rather than focusing on the negative side, try to figure out a way to
>> make
>> > it work :)
>> >
>> > Back to the proposal from Jens and you -  Yes that (a comment allowing
>> to
>> > still merge/auto-merge the PR) alleviates my concern.
>> >
>> > Regards,
>> > Kaxil
>> >
>> >
>> >
>> > On Thu, 1 May 2025 at 12:54, Jarek Potiuk <ja...@potiuk.com> wrote:
>> >
>> > > I really like Jens's line of thought. Rather than focusing on the
>> > negative
>> > > side, try to figure out a way to make it work :). That's very
>> inspiring.
>> > >
>> > > I think the original slack proposal of Jens was rather brittle, but it
>> > made
>> > > me think that we can actually implement what we need rather quickly.
>> > >
>> > > Following the `Dependabot` style @rebase - we could implement - very
>> > easily
>> > > - there are ready actions for that and other projects like apache beam
>> > are
>> > > using similar workflows - the comment workflow, where maintainer who
>> > wants
>> > > to merge  (or auto-merge) such "failing" PR would just comment it
>> > > appropriately.
>> > >
>> > > What we really want is to make the "finalize" check succeed, so if
>> the PR
>> > > misses the "Finalize" step, a committer would just have to comment it
>> > with
>> > > "@bypass-finalize` or `@finalize` or similar. And what it would do, it
>> > > would use Github API to make the "Finalize" check succeed. There is an
>> > API
>> > > for that.
>> > >
>> > > That has a few nice properties:
>> > >
>> > > * it uses the same GitHub UI we use, no need to have an "escape hatch"
>> > and
>> > > separate remote
>> > > * it follows the pattern we already agreed to some time ago and
>> generally
>> > > follow -> we are supposed (as maintainers) to explain when we are
>> merging
>> > > such failing PR to show that this is a deliberate action - I usually
>> for
>> > > example always add "fixed already in main" or "Fixed already by #..."
>> > > comment - you really need a comment in this case explaining that it
>> was
>> > not
>> > > accidental "merge".
>> > > * so if we have such workflow, it would "force" maintainer to make a
>> > > deliberate decision "yes I want to merge it despite failing" and make
>> a
>> > > comment in the PR
>> > > * it would only set the "finalize" check to succeed, so still you
>> would
>> > not
>> > > be able to merge it without having an approval - this would only
>> bypass
>> > the
>> > > "finalize" check
>> > >
>> > > WDYT? Would that address all concerns with auto-merge ? Does it make
>> > sense
>> > > and is it "easy enough" to follow? Or are there any other concerns?
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Apr 30, 2025 at 10:36 PM Pavankumar Gopidesu <
>> > > gopidesupavan@gmail.com> wrote:
>> > >
>> > > > I am also in line with Jens. The auto-merge feature works well in
>> > keeping
>> > > > the CI pipeline green before merging.
>> > > > However, there are situations where we need to merge changes
>> quickly.
>> > > > Instead of using an
>> > > > escape route (which I’m not a fan of, as it carries risks if
>> something
>> > > goes
>> > > > wrong—even though we can revert, it’s still a concern),
>> > > > we could explore ways to dynamically bypass certain checks when
>> > necessary
>> > > > or maybe some help from INFRA?
>> > > >
>> > > > Pavan
>> > > >
>> > > > On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler
>> > > <j_scheffler@gmx.de.invalid
>> > > > >
>> > > > wrote:
>> > > >
>> > > > > As there was a call for more opinions. Here I am :-D
>> > > > >
>> > > > > I understand both positions. As I like AutoMerge very much I am
>> not
>> > > > > giving up :-D I'd like to keep it.
>> > > > >
>> > > > > I think there is still an option in between. Maybe need to draft a
>> > bit
>> > > > > of thoughts but I think we could build something still around the
>> > > > > limitations allowing automation.
>> > > > >
>> > > > > Added a minor thought to the slack chat. But if community rules
>> > propose
>> > > > > to push to devchennel let me know.
>> > > > >
>> > > > > Jens
>> > > > >
>> > > > > On 30.04.25 11:04, Jarek Potiuk wrote:
>> > > > > > Yeah, And I would encourage everyone to try it and provide
>> feedback
>> > > > while
>> > > > > > it is enabled.
>> > > > > >
>> > > > > > So far we identified a few things (and fix them) that made it
>> > > > borderline
>> > > > > > unusable (bug in workflow for UI-only changes, GitHub starting
>> to
>> > > > 429-us
>> > > > > > with too many requests, and the mysterious "hanging" of the
>> latest
>> > > > > > botocore/celery (?) "special tests" -> all that is already
>> > addressed
>> > > in
>> > > > > > main, and those issues should not happen (hopefully), so I'd
>> say we
>> > > can
>> > > > > now
>> > > > > > "truly" see how it might work.
>> > > > > >
>> > > > > > And one comment from my side - indeed, I find it nice actually,
>> but
>> > > > it's
>> > > > > > definitely not a "deal breaker"- so if others find it too
>> > > disruptive, I
>> > > > > am
>> > > > > > definitely not going to die on this hill, I just thought it does
>> > > > improve
>> > > > > > the workflow in the way that it allows for mostly "fire and
>> forget"
>> > > > when
>> > > > > > you approve the workflow, one thing that it definitely improves
>> is
>> > > that
>> > > > > you
>> > > > > > do not have to remember about coming back to merge a request
>> when
>> > CI
>> > > > > > succeeds.
>> > > > > >
>> > > > > > J.
>> > > > > >
>> > > > > > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <
>> kaxilnaik@gmail.com>
>> > > > wrote:
>> > > > > >
>> > > > > >> Forgot to note an additional point in Summary: If we find
>> anything
>> > > > > blocking
>> > > > > >> us in that period, we will merge
>> > > > > >> https://github.com/apache/airflow/pull/50009 to disable
>> > auto-merge.
>> > > > > >>
>> > > > > >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <ka...@gmail.com>
>> > > wrote:
>> > > > > >>
>> > > > > >>> Jarek & I discussed it on Slack in #internal-airflow-ci-cd.
>> > Summary
>> > > > > >> below:
>> > > > > >>> I have a PR to disable it:
>> > > > > https://github.com/apache/airflow/pull/50009.
>> > > > > >>> However, given that many countries will be on holiday on May 1
>> > due
>> > > to
>> > > > > >>> Labour Day, and some teething issues were fixed yesterday, we
>> > will
>> > > > let
>> > > > > it
>> > > > > >>> run for a few more days so other committers and contributors
>> can
>> > > get
>> > > > a
>> > > > > >>> chance to try it out and share their experience after the
>> > > > > >> experiment/trial
>> > > > > >>> is concluded.
>> > > > > >>>
>> > > > > >>>
>> > > > > >>>
>> > > > > >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <kaxilnaik@gmail.com
>> >
>> > > > wrote:
>> > > > > >>>
>> > > > > >>>> Whoops yeah.
>> > > > > >>>>
>> > > > > >>>>> Yep. Because it did not have all conversations resolved. We
>> > also
>> > > > have
>> > > > > >>>> "require resolved conversation" as one of the branch
>> protection
>> > > > > >>>> conditions.
>> > > > > >>>> I resolved the conversation and it got merged automatically.
>> > > > > >>>>
>> > > > > >>>> Let's adapt it when ready though, I don't see any urgency of
>> > > getting
>> > > > > >>>> enabling auto-merge or getting it contributed immediately to
>> asf
>> > > > INFRA
>> > > > > >> when
>> > > > > >>>> it isn't critical. It is about priortization
>> > > > > >>>>
>> > > > > >>>> I'd say - if that is really bothering us - let's shape the
>> > feature
>> > > > > >> rather
>> > > > > >>>>> than outright reject it.
>> > > > > >>>>
>> > > > > >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <jarek@potiuk.com
>> >
>> > > > wrote:
>> > > > > >>>>
>> > > > > >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <
>> > kaxilnaik@gmail.com>
>> > > > > >> wrote:
>> > > > > >>>>>> To the point that the original PR is still not merged even
>> > > after I
>> > > > > >> had
>> > > > > >>>>>> re-triggered the failed tests yesterday:
>> > > > > >>>>>> https://github.com/apache/airflow/pull/49727
>> > > > > >>>>>>
>> > > > > >>>>>>
>> > > > > >>>>> Yep. Because it did not have all conversations resolved. We
>> > also
>> > > > have
>> > > > > >>>>> "require resolved conversation" as one of the branch
>> protection
>> > > > > >>>>> conditions.
>> > > > > >>>>> I resolved the conversation and it got merged automatically.
>> > > > > >>>>>
>> > > > > >>>>>
>> > > > > >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <
>> kaxilnaik@gmail.com
>> > >
>> > > > > >> wrote:
>> > > > > >>>>>>> The gitbox escape hatch isn't it though -- if we are to
>> allow
>> > > > that
>> > > > > >>>>> why
>> > > > > >>>>>> not
>> > > > > >>>>>>> just allow people to merge it directly from github that
>> to go
>> > > via
>> > > > > >> an
>> > > > > >>>>>>> "escape hatch".
>> > > > > >>>>> Generally speaking GitHub has this option. Currently
>> "admins"
>> > > have
>> > > > a
>> > > > > >>>>> possibility of overriding branch protection (via UI). And it
>> > > would
>> > > > be
>> > > > > >>>>> possible - if INFRA will allow it - to possibly add an
>> > .asf.yaml
>> > > > > >> feature
>> > > > > >>>>> to
>> > > > > >>>>> also allow branch protection override for all committers or
>> a
>> > > > subset
>> > > > > of
>> > > > > >>>>> the
>> > > > > >>>>> committers (PMC Members ? ). This is more of a limitation of
>> > the
>> > > > > >> current
>> > > > > >>>>> implementation of permissions than a missing feature. If we
>> all
>> > > > feel
>> > > > > >> that
>> > > > > >>>>> the gitbox escape hatch is not enough, we can likely even
>> > > > contribute
>> > > > > >>>>> such a
>> > > > > >>>>> feature to .asf.yaml - if INFRA will be ok with the option.
>> > It's
>> > > > very
>> > > > > >>>>> easy
>> > > > > >>>>> to contribute to - INFRA made it possible, we have a new
>> > > framework:
>> > > > > >>>>> https://github.com/apache/infrastructure-asfyaml - we can
>> even
>> > > > > >> implement
>> > > > > >>>>> "airflow-only" .asf.yaml feature, that will not be initially
>> > > > > available
>> > > > > >> to
>> > > > > >>>>> other ASF projects and later we can promote it to be
>> available
>> > to
>> > > > > >>>>> everyone.
>> > > > > >>>>>
>> > > > > >>>>> I'd say - if that is really bothering us - let's shape the
>> > > feature
>> > > > > >> rather
>> > > > > >>>>> than outright reject it.
>> > > > > >>>>>
>> > > > > >>>>>
>> > > > > >>>>>>> I am -1 on this auto-merge feature
>> > > > > >>>>>>>
>> > > > > >>>>> Understood :). But let's give it a bit more time as well and
>> > > maybe
>> > > > > >>>>> improve
>> > > > > >>>>> it (see above) - unless we really feel we are blocked now -
>> > then
>> > > it
>> > > > > >>>>> should
>> > > > > >>>>> be as easy as merging an .asf.yaml change to disable it.
>> > > > > >>>>>
>> > > > > >>>>>
>> > > > > >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <
>> > kaxilnaik@gmail.com>
>> > > > > >>>>> wrote:
>> > > > > >>>>>>>> That’s not a single person, it impacts the committers and
>> > the
>> > > PR
>> > > > > >>>>> author
>> > > > > >>>>>>>> involved too. I don’t see how team productivity soars
>> here.
>> > > > > >>>>>>>>
>> > > > > >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <
>> > jarek@potiuk.com>
>> > > > > >>>>> wrote:
>> > > > > >>>>>>>>> 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 <
>> > > > jarek@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 <
>> > > > > >> kaxilnaik@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 <
>> > > jarek@potiuk.com
>> > > > >
>> > > > > >>>>>> wrote:
>> > > > > >>>>>>>>>>>> On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <
>> > > > > >>>>> eladkal@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,
>> > > > > >>>>>>>>>>>>
>> > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
>> > > > > For additional commands, e-mail: dev-help@airflow.apache.org
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

"-1" was backed with rationale discussion and no one has said it was a bad
idea but you have said it is "negative".

On Thu, 1 May 2025 at 14:59, Jarek Potiuk <ja...@potiuk.com> wrote:

> > That said, I want to push back on the framing of some feedback as
> “negative.” I really appreciate the folks who raised concerns, those
> perspectives are vital to making the project stronger and more inclusive.
>
> I think what I wanted to say is that I think we should all exercise
> empathy. It's super easy to say "-1" but it's harder to say "It's a good
> idea but ..". Psychological effect of the "-1" is that it "cuts the wings"
> of the person who has some idea and wants to follow it through. The
> psychological effect of "cool idea, but" is that it - more often than not -
> make the person more energised and inspired to look for a better solution.
>
> And yes I know different people have different communication style, and
> there are cultural differences and all that. But I would personally love to
> see more "yes, but" than "no".
>
> That's all I want to say..
>
> J/
>
>
>
>
>
> On Thu, May 1, 2025 at 11:23 AM Kaxil Naik <ka...@gmail.com> wrote:
>
> > Thanks for the energy and initiative here.
> >
> > That said, I want to push back on the framing of some feedback as
> > “negative.” I really appreciate the folks who raised concerns, those
> > perspectives are vital to making the project stronger and more inclusive.
> >
> > Let’s make sure we continue to welcome both enthusiasm and critique. As
> > the ASF
> > Code of Conduct <https://www.apache.org/foundation/policies/conduct>
> > reminds us, thoughtful disagreement and diverse viewpoints are not only
> > expected but encouraged. Referring to concerns as “negative”, even
> > unintentionally, can discourage people from speaking up, which we want to
> > avoid.
> >
> > We all want what’s best for Airflow, and part of that is making sure
> > everyone feels safe to contribute, especially when something doesn’t feel
> > right.
> >
> > >Rather than focusing on the negative side, try to figure out a way to
> make
> > it work :)
> >
> > Back to the proposal from Jens and you -  Yes that (a comment allowing to
> > still merge/auto-merge the PR) alleviates my concern.
> >
> > Regards,
> > Kaxil
> >
> >
> >
> > On Thu, 1 May 2025 at 12:54, Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > > I really like Jens's line of thought. Rather than focusing on the
> > negative
> > > side, try to figure out a way to make it work :). That's very
> inspiring.
> > >
> > > I think the original slack proposal of Jens was rather brittle, but it
> > made
> > > me think that we can actually implement what we need rather quickly.
> > >
> > > Following the `Dependabot` style @rebase - we could implement - very
> > easily
> > > - there are ready actions for that and other projects like apache beam
> > are
> > > using similar workflows - the comment workflow, where maintainer who
> > wants
> > > to merge  (or auto-merge) such "failing" PR would just comment it
> > > appropriately.
> > >
> > > What we really want is to make the "finalize" check succeed, so if the
> PR
> > > misses the "Finalize" step, a committer would just have to comment it
> > with
> > > "@bypass-finalize` or `@finalize` or similar. And what it would do, it
> > > would use Github API to make the "Finalize" check succeed. There is an
> > API
> > > for that.
> > >
> > > That has a few nice properties:
> > >
> > > * it uses the same GitHub UI we use, no need to have an "escape hatch"
> > and
> > > separate remote
> > > * it follows the pattern we already agreed to some time ago and
> generally
> > > follow -> we are supposed (as maintainers) to explain when we are
> merging
> > > such failing PR to show that this is a deliberate action - I usually
> for
> > > example always add "fixed already in main" or "Fixed already by #..."
> > > comment - you really need a comment in this case explaining that it was
> > not
> > > accidental "merge".
> > > * so if we have such workflow, it would "force" maintainer to make a
> > > deliberate decision "yes I want to merge it despite failing" and make a
> > > comment in the PR
> > > * it would only set the "finalize" check to succeed, so still you would
> > not
> > > be able to merge it without having an approval - this would only bypass
> > the
> > > "finalize" check
> > >
> > > WDYT? Would that address all concerns with auto-merge ? Does it make
> > sense
> > > and is it "easy enough" to follow? Or are there any other concerns?
> > >
> > >
> > >
> > >
> > > On Wed, Apr 30, 2025 at 10:36 PM Pavankumar Gopidesu <
> > > gopidesupavan@gmail.com> wrote:
> > >
> > > > I am also in line with Jens. The auto-merge feature works well in
> > keeping
> > > > the CI pipeline green before merging.
> > > > However, there are situations where we need to merge changes quickly.
> > > > Instead of using an
> > > > escape route (which I’m not a fan of, as it carries risks if
> something
> > > goes
> > > > wrong—even though we can revert, it’s still a concern),
> > > > we could explore ways to dynamically bypass certain checks when
> > necessary
> > > > or maybe some help from INFRA?
> > > >
> > > > Pavan
> > > >
> > > > On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler
> > > <j_scheffler@gmx.de.invalid
> > > > >
> > > > wrote:
> > > >
> > > > > As there was a call for more opinions. Here I am :-D
> > > > >
> > > > > I understand both positions. As I like AutoMerge very much I am not
> > > > > giving up :-D I'd like to keep it.
> > > > >
> > > > > I think there is still an option in between. Maybe need to draft a
> > bit
> > > > > of thoughts but I think we could build something still around the
> > > > > limitations allowing automation.
> > > > >
> > > > > Added a minor thought to the slack chat. But if community rules
> > propose
> > > > > to push to devchennel let me know.
> > > > >
> > > > > Jens
> > > > >
> > > > > On 30.04.25 11:04, Jarek Potiuk wrote:
> > > > > > Yeah, And I would encourage everyone to try it and provide
> feedback
> > > > while
> > > > > > it is enabled.
> > > > > >
> > > > > > So far we identified a few things (and fix them) that made it
> > > > borderline
> > > > > > unusable (bug in workflow for UI-only changes, GitHub starting to
> > > > 429-us
> > > > > > with too many requests, and the mysterious "hanging" of the
> latest
> > > > > > botocore/celery (?) "special tests" -> all that is already
> > addressed
> > > in
> > > > > > main, and those issues should not happen (hopefully), so I'd say
> we
> > > can
> > > > > now
> > > > > > "truly" see how it might work.
> > > > > >
> > > > > > And one comment from my side - indeed, I find it nice actually,
> but
> > > > it's
> > > > > > definitely not a "deal breaker"- so if others find it too
> > > disruptive, I
> > > > > am
> > > > > > definitely not going to die on this hill, I just thought it does
> > > > improve
> > > > > > the workflow in the way that it allows for mostly "fire and
> forget"
> > > > when
> > > > > > you approve the workflow, one thing that it definitely improves
> is
> > > that
> > > > > you
> > > > > > do not have to remember about coming back to merge a request when
> > CI
> > > > > > succeeds.
> > > > > >
> > > > > > J.
> > > > > >
> > > > > > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <kaxilnaik@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > >> Forgot to note an additional point in Summary: If we find
> anything
> > > > > blocking
> > > > > >> us in that period, we will merge
> > > > > >> https://github.com/apache/airflow/pull/50009 to disable
> > auto-merge.
> > > > > >>
> > > > > >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <ka...@gmail.com>
> > > wrote:
> > > > > >>
> > > > > >>> Jarek & I discussed it on Slack in #internal-airflow-ci-cd.
> > Summary
> > > > > >> below:
> > > > > >>> I have a PR to disable it:
> > > > > https://github.com/apache/airflow/pull/50009.
> > > > > >>> However, given that many countries will be on holiday on May 1
> > due
> > > to
> > > > > >>> Labour Day, and some teething issues were fixed yesterday, we
> > will
> > > > let
> > > > > it
> > > > > >>> run for a few more days so other committers and contributors
> can
> > > get
> > > > a
> > > > > >>> chance to try it out and share their experience after the
> > > > > >> experiment/trial
> > > > > >>> is concluded.
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <ka...@gmail.com>
> > > > wrote:
> > > > > >>>
> > > > > >>>> Whoops yeah.
> > > > > >>>>
> > > > > >>>>> Yep. Because it did not have all conversations resolved. We
> > also
> > > > have
> > > > > >>>> "require resolved conversation" as one of the branch
> protection
> > > > > >>>> conditions.
> > > > > >>>> I resolved the conversation and it got merged automatically.
> > > > > >>>>
> > > > > >>>> Let's adapt it when ready though, I don't see any urgency of
> > > getting
> > > > > >>>> enabling auto-merge or getting it contributed immediately to
> asf
> > > > INFRA
> > > > > >> when
> > > > > >>>> it isn't critical. It is about priortization
> > > > > >>>>
> > > > > >>>> I'd say - if that is really bothering us - let's shape the
> > feature
> > > > > >> rather
> > > > > >>>>> than outright reject it.
> > > > > >>>>
> > > > > >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <ja...@potiuk.com>
> > > > wrote:
> > > > > >>>>
> > > > > >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <
> > kaxilnaik@gmail.com>
> > > > > >> wrote:
> > > > > >>>>>> To the point that the original PR is still not merged even
> > > after I
> > > > > >> had
> > > > > >>>>>> re-triggered the failed tests yesterday:
> > > > > >>>>>> https://github.com/apache/airflow/pull/49727
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>> Yep. Because it did not have all conversations resolved. We
> > also
> > > > have
> > > > > >>>>> "require resolved conversation" as one of the branch
> protection
> > > > > >>>>> conditions.
> > > > > >>>>> I resolved the conversation and it got merged automatically.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <
> kaxilnaik@gmail.com
> > >
> > > > > >> wrote:
> > > > > >>>>>>> The gitbox escape hatch isn't it though -- if we are to
> allow
> > > > that
> > > > > >>>>> why
> > > > > >>>>>> not
> > > > > >>>>>>> just allow people to merge it directly from github that to
> go
> > > via
> > > > > >> an
> > > > > >>>>>>> "escape hatch".
> > > > > >>>>> Generally speaking GitHub has this option. Currently "admins"
> > > have
> > > > a
> > > > > >>>>> possibility of overriding branch protection (via UI). And it
> > > would
> > > > be
> > > > > >>>>> possible - if INFRA will allow it - to possibly add an
> > .asf.yaml
> > > > > >> feature
> > > > > >>>>> to
> > > > > >>>>> also allow branch protection override for all committers or a
> > > > subset
> > > > > of
> > > > > >>>>> the
> > > > > >>>>> committers (PMC Members ? ). This is more of a limitation of
> > the
> > > > > >> current
> > > > > >>>>> implementation of permissions than a missing feature. If we
> all
> > > > feel
> > > > > >> that
> > > > > >>>>> the gitbox escape hatch is not enough, we can likely even
> > > > contribute
> > > > > >>>>> such a
> > > > > >>>>> feature to .asf.yaml - if INFRA will be ok with the option.
> > It's
> > > > very
> > > > > >>>>> easy
> > > > > >>>>> to contribute to - INFRA made it possible, we have a new
> > > framework:
> > > > > >>>>> https://github.com/apache/infrastructure-asfyaml - we can
> even
> > > > > >> implement
> > > > > >>>>> "airflow-only" .asf.yaml feature, that will not be initially
> > > > > available
> > > > > >> to
> > > > > >>>>> other ASF projects and later we can promote it to be
> available
> > to
> > > > > >>>>> everyone.
> > > > > >>>>>
> > > > > >>>>> I'd say - if that is really bothering us - let's shape the
> > > feature
> > > > > >> rather
> > > > > >>>>> than outright reject it.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>>> I am -1 on this auto-merge feature
> > > > > >>>>>>>
> > > > > >>>>> Understood :). But let's give it a bit more time as well and
> > > maybe
> > > > > >>>>> improve
> > > > > >>>>> it (see above) - unless we really feel we are blocked now -
> > then
> > > it
> > > > > >>>>> should
> > > > > >>>>> be as easy as merging an .asf.yaml change to disable it.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <
> > kaxilnaik@gmail.com>
> > > > > >>>>> wrote:
> > > > > >>>>>>>> That’s not a single person, it impacts the committers and
> > the
> > > PR
> > > > > >>>>> author
> > > > > >>>>>>>> involved too. I don’t see how team productivity soars
> here.
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <
> > jarek@potiuk.com>
> > > > > >>>>> wrote:
> > > > > >>>>>>>>> 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 <
> > > > jarek@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 <
> > > > > >> kaxilnaik@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 <
> > > jarek@potiuk.com
> > > > >
> > > > > >>>>>> wrote:
> > > > > >>>>>>>>>>>> On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <
> > > > > >>>>> eladkal@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,
> > > > > >>>>>>>>>>>>
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > > > > For additional commands, e-mail: dev-help@airflow.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

> That said, I want to push back on the framing of some feedback as
“negative.” I really appreciate the folks who raised concerns, those
perspectives are vital to making the project stronger and more inclusive.

I think what I wanted to say is that I think we should all exercise
empathy. It's super easy to say "-1" but it's harder to say "It's a good
idea but ..". Psychological effect of the "-1" is that it "cuts the wings"
of the person who has some idea and wants to follow it through. The
psychological effect of "cool idea, but" is that it - more often than not -
make the person more energised and inspired to look for a better solution.

And yes I know different people have different communication style, and
there are cultural differences and all that. But I would personally love to
see more "yes, but" than "no".

That's all I want to say..

J/





On Thu, May 1, 2025 at 11:23 AM Kaxil Naik <ka...@gmail.com> wrote:

> Thanks for the energy and initiative here.
>
> That said, I want to push back on the framing of some feedback as
> “negative.” I really appreciate the folks who raised concerns, those
> perspectives are vital to making the project stronger and more inclusive.
>
> Let’s make sure we continue to welcome both enthusiasm and critique. As
> the ASF
> Code of Conduct <https://www.apache.org/foundation/policies/conduct>
> reminds us, thoughtful disagreement and diverse viewpoints are not only
> expected but encouraged. Referring to concerns as “negative”, even
> unintentionally, can discourage people from speaking up, which we want to
> avoid.
>
> We all want what’s best for Airflow, and part of that is making sure
> everyone feels safe to contribute, especially when something doesn’t feel
> right.
>
> >Rather than focusing on the negative side, try to figure out a way to make
> it work :)
>
> Back to the proposal from Jens and you -  Yes that (a comment allowing to
> still merge/auto-merge the PR) alleviates my concern.
>
> Regards,
> Kaxil
>
>
>
> On Thu, 1 May 2025 at 12:54, Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > I really like Jens's line of thought. Rather than focusing on the
> negative
> > side, try to figure out a way to make it work :). That's very inspiring.
> >
> > I think the original slack proposal of Jens was rather brittle, but it
> made
> > me think that we can actually implement what we need rather quickly.
> >
> > Following the `Dependabot` style @rebase - we could implement - very
> easily
> > - there are ready actions for that and other projects like apache beam
> are
> > using similar workflows - the comment workflow, where maintainer who
> wants
> > to merge  (or auto-merge) such "failing" PR would just comment it
> > appropriately.
> >
> > What we really want is to make the "finalize" check succeed, so if the PR
> > misses the "Finalize" step, a committer would just have to comment it
> with
> > "@bypass-finalize` or `@finalize` or similar. And what it would do, it
> > would use Github API to make the "Finalize" check succeed. There is an
> API
> > for that.
> >
> > That has a few nice properties:
> >
> > * it uses the same GitHub UI we use, no need to have an "escape hatch"
> and
> > separate remote
> > * it follows the pattern we already agreed to some time ago and generally
> > follow -> we are supposed (as maintainers) to explain when we are merging
> > such failing PR to show that this is a deliberate action - I usually for
> > example always add "fixed already in main" or "Fixed already by #..."
> > comment - you really need a comment in this case explaining that it was
> not
> > accidental "merge".
> > * so if we have such workflow, it would "force" maintainer to make a
> > deliberate decision "yes I want to merge it despite failing" and make a
> > comment in the PR
> > * it would only set the "finalize" check to succeed, so still you would
> not
> > be able to merge it without having an approval - this would only bypass
> the
> > "finalize" check
> >
> > WDYT? Would that address all concerns with auto-merge ? Does it make
> sense
> > and is it "easy enough" to follow? Or are there any other concerns?
> >
> >
> >
> >
> > On Wed, Apr 30, 2025 at 10:36 PM Pavankumar Gopidesu <
> > gopidesupavan@gmail.com> wrote:
> >
> > > I am also in line with Jens. The auto-merge feature works well in
> keeping
> > > the CI pipeline green before merging.
> > > However, there are situations where we need to merge changes quickly.
> > > Instead of using an
> > > escape route (which I’m not a fan of, as it carries risks if something
> > goes
> > > wrong—even though we can revert, it’s still a concern),
> > > we could explore ways to dynamically bypass certain checks when
> necessary
> > > or maybe some help from INFRA?
> > >
> > > Pavan
> > >
> > > On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler
> > <j_scheffler@gmx.de.invalid
> > > >
> > > wrote:
> > >
> > > > As there was a call for more opinions. Here I am :-D
> > > >
> > > > I understand both positions. As I like AutoMerge very much I am not
> > > > giving up :-D I'd like to keep it.
> > > >
> > > > I think there is still an option in between. Maybe need to draft a
> bit
> > > > of thoughts but I think we could build something still around the
> > > > limitations allowing automation.
> > > >
> > > > Added a minor thought to the slack chat. But if community rules
> propose
> > > > to push to devchennel let me know.
> > > >
> > > > Jens
> > > >
> > > > On 30.04.25 11:04, Jarek Potiuk wrote:
> > > > > Yeah, And I would encourage everyone to try it and provide feedback
> > > while
> > > > > it is enabled.
> > > > >
> > > > > So far we identified a few things (and fix them) that made it
> > > borderline
> > > > > unusable (bug in workflow for UI-only changes, GitHub starting to
> > > 429-us
> > > > > with too many requests, and the mysterious "hanging" of the latest
> > > > > botocore/celery (?) "special tests" -> all that is already
> addressed
> > in
> > > > > main, and those issues should not happen (hopefully), so I'd say we
> > can
> > > > now
> > > > > "truly" see how it might work.
> > > > >
> > > > > And one comment from my side - indeed, I find it nice actually, but
> > > it's
> > > > > definitely not a "deal breaker"- so if others find it too
> > disruptive, I
> > > > am
> > > > > definitely not going to die on this hill, I just thought it does
> > > improve
> > > > > the workflow in the way that it allows for mostly "fire and forget"
> > > when
> > > > > you approve the workflow, one thing that it definitely improves is
> > that
> > > > you
> > > > > do not have to remember about coming back to merge a request when
> CI
> > > > > succeeds.
> > > > >
> > > > > J.
> > > > >
> > > > > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <ka...@gmail.com>
> > > wrote:
> > > > >
> > > > >> Forgot to note an additional point in Summary: If we find anything
> > > > blocking
> > > > >> us in that period, we will merge
> > > > >> https://github.com/apache/airflow/pull/50009 to disable
> auto-merge.
> > > > >>
> > > > >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <ka...@gmail.com>
> > wrote:
> > > > >>
> > > > >>> Jarek & I discussed it on Slack in #internal-airflow-ci-cd.
> Summary
> > > > >> below:
> > > > >>> I have a PR to disable it:
> > > > https://github.com/apache/airflow/pull/50009.
> > > > >>> However, given that many countries will be on holiday on May 1
> due
> > to
> > > > >>> Labour Day, and some teething issues were fixed yesterday, we
> will
> > > let
> > > > it
> > > > >>> run for a few more days so other committers and contributors can
> > get
> > > a
> > > > >>> chance to try it out and share their experience after the
> > > > >> experiment/trial
> > > > >>> is concluded.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <ka...@gmail.com>
> > > wrote:
> > > > >>>
> > > > >>>> Whoops yeah.
> > > > >>>>
> > > > >>>>> Yep. Because it did not have all conversations resolved. We
> also
> > > have
> > > > >>>> "require resolved conversation" as one of the branch protection
> > > > >>>> conditions.
> > > > >>>> I resolved the conversation and it got merged automatically.
> > > > >>>>
> > > > >>>> Let's adapt it when ready though, I don't see any urgency of
> > getting
> > > > >>>> enabling auto-merge or getting it contributed immediately to asf
> > > INFRA
> > > > >> when
> > > > >>>> it isn't critical. It is about priortization
> > > > >>>>
> > > > >>>> I'd say - if that is really bothering us - let's shape the
> feature
> > > > >> rather
> > > > >>>>> than outright reject it.
> > > > >>>>
> > > > >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <ja...@potiuk.com>
> > > wrote:
> > > > >>>>
> > > > >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <
> kaxilnaik@gmail.com>
> > > > >> wrote:
> > > > >>>>>> To the point that the original PR is still not merged even
> > after I
> > > > >> had
> > > > >>>>>> re-triggered the failed tests yesterday:
> > > > >>>>>> https://github.com/apache/airflow/pull/49727
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>> Yep. Because it did not have all conversations resolved. We
> also
> > > have
> > > > >>>>> "require resolved conversation" as one of the branch protection
> > > > >>>>> conditions.
> > > > >>>>> I resolved the conversation and it got merged automatically.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <kaxilnaik@gmail.com
> >
> > > > >> wrote:
> > > > >>>>>>> The gitbox escape hatch isn't it though -- if we are to allow
> > > that
> > > > >>>>> why
> > > > >>>>>> not
> > > > >>>>>>> just allow people to merge it directly from github that to go
> > via
> > > > >> an
> > > > >>>>>>> "escape hatch".
> > > > >>>>> Generally speaking GitHub has this option. Currently "admins"
> > have
> > > a
> > > > >>>>> possibility of overriding branch protection (via UI). And it
> > would
> > > be
> > > > >>>>> possible - if INFRA will allow it - to possibly add an
> .asf.yaml
> > > > >> feature
> > > > >>>>> to
> > > > >>>>> also allow branch protection override for all committers or a
> > > subset
> > > > of
> > > > >>>>> the
> > > > >>>>> committers (PMC Members ? ). This is more of a limitation of
> the
> > > > >> current
> > > > >>>>> implementation of permissions than a missing feature. If we all
> > > feel
> > > > >> that
> > > > >>>>> the gitbox escape hatch is not enough, we can likely even
> > > contribute
> > > > >>>>> such a
> > > > >>>>> feature to .asf.yaml - if INFRA will be ok with the option.
> It's
> > > very
> > > > >>>>> easy
> > > > >>>>> to contribute to - INFRA made it possible, we have a new
> > framework:
> > > > >>>>> https://github.com/apache/infrastructure-asfyaml - we can even
> > > > >> implement
> > > > >>>>> "airflow-only" .asf.yaml feature, that will not be initially
> > > > available
> > > > >> to
> > > > >>>>> other ASF projects and later we can promote it to be available
> to
> > > > >>>>> everyone.
> > > > >>>>>
> > > > >>>>> I'd say - if that is really bothering us - let's shape the
> > feature
> > > > >> rather
> > > > >>>>> than outright reject it.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>> I am -1 on this auto-merge feature
> > > > >>>>>>>
> > > > >>>>> Understood :). But let's give it a bit more time as well and
> > maybe
> > > > >>>>> improve
> > > > >>>>> it (see above) - unless we really feel we are blocked now -
> then
> > it
> > > > >>>>> should
> > > > >>>>> be as easy as merging an .asf.yaml change to disable it.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <
> kaxilnaik@gmail.com>
> > > > >>>>> wrote:
> > > > >>>>>>>> That’s not a single person, it impacts the committers and
> the
> > PR
> > > > >>>>> author
> > > > >>>>>>>> involved too. I don’t see how team productivity soars here.
> > > > >>>>>>>>
> > > > >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <
> jarek@potiuk.com>
> > > > >>>>> wrote:
> > > > >>>>>>>>> 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 <
> > > jarek@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 <
> > > > >> kaxilnaik@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 <
> > jarek@potiuk.com
> > > >
> > > > >>>>>> wrote:
> > > > >>>>>>>>>>>> On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <
> > > > >>>>> eladkal@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,
> > > > >>>>>>>>>>>>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > > > For additional commands, e-mail: dev-help@airflow.apache.org
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

Thanks for the energy and initiative here.

That said, I want to push back on the framing of some feedback as
“negative.” I really appreciate the folks who raised concerns, those
perspectives are vital to making the project stronger and more inclusive.

Let’s make sure we continue to welcome both enthusiasm and critique. As the ASF
Code of Conduct <https://www.apache.org/foundation/policies/conduct>
reminds us, thoughtful disagreement and diverse viewpoints are not only
expected but encouraged. Referring to concerns as “negative”, even
unintentionally, can discourage people from speaking up, which we want to
avoid.

We all want what’s best for Airflow, and part of that is making sure
everyone feels safe to contribute, especially when something doesn’t feel
right.

>Rather than focusing on the negative side, try to figure out a way to make
it work :)

Back to the proposal from Jens and you -  Yes that (a comment allowing to
still merge/auto-merge the PR) alleviates my concern.

Regards,
Kaxil



On Thu, 1 May 2025 at 12:54, Jarek Potiuk <ja...@potiuk.com> wrote:

> I really like Jens's line of thought. Rather than focusing on the negative
> side, try to figure out a way to make it work :). That's very inspiring.
>
> I think the original slack proposal of Jens was rather brittle, but it made
> me think that we can actually implement what we need rather quickly.
>
> Following the `Dependabot` style @rebase - we could implement - very easily
> - there are ready actions for that and other projects like apache beam are
> using similar workflows - the comment workflow, where maintainer who wants
> to merge  (or auto-merge) such "failing" PR would just comment it
> appropriately.
>
> What we really want is to make the "finalize" check succeed, so if the PR
> misses the "Finalize" step, a committer would just have to comment it with
> "@bypass-finalize` or `@finalize` or similar. And what it would do, it
> would use Github API to make the "Finalize" check succeed. There is an API
> for that.
>
> That has a few nice properties:
>
> * it uses the same GitHub UI we use, no need to have an "escape hatch" and
> separate remote
> * it follows the pattern we already agreed to some time ago and generally
> follow -> we are supposed (as maintainers) to explain when we are merging
> such failing PR to show that this is a deliberate action - I usually for
> example always add "fixed already in main" or "Fixed already by #..."
> comment - you really need a comment in this case explaining that it was not
> accidental "merge".
> * so if we have such workflow, it would "force" maintainer to make a
> deliberate decision "yes I want to merge it despite failing" and make a
> comment in the PR
> * it would only set the "finalize" check to succeed, so still you would not
> be able to merge it without having an approval - this would only bypass the
> "finalize" check
>
> WDYT? Would that address all concerns with auto-merge ? Does it make sense
> and is it "easy enough" to follow? Or are there any other concerns?
>
>
>
>
> On Wed, Apr 30, 2025 at 10:36 PM Pavankumar Gopidesu <
> gopidesupavan@gmail.com> wrote:
>
> > I am also in line with Jens. The auto-merge feature works well in keeping
> > the CI pipeline green before merging.
> > However, there are situations where we need to merge changes quickly.
> > Instead of using an
> > escape route (which I’m not a fan of, as it carries risks if something
> goes
> > wrong—even though we can revert, it’s still a concern),
> > we could explore ways to dynamically bypass certain checks when necessary
> > or maybe some help from INFRA?
> >
> > Pavan
> >
> > On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler
> <j_scheffler@gmx.de.invalid
> > >
> > wrote:
> >
> > > As there was a call for more opinions. Here I am :-D
> > >
> > > I understand both positions. As I like AutoMerge very much I am not
> > > giving up :-D I'd like to keep it.
> > >
> > > I think there is still an option in between. Maybe need to draft a bit
> > > of thoughts but I think we could build something still around the
> > > limitations allowing automation.
> > >
> > > Added a minor thought to the slack chat. But if community rules propose
> > > to push to devchennel let me know.
> > >
> > > Jens
> > >
> > > On 30.04.25 11:04, Jarek Potiuk wrote:
> > > > Yeah, And I would encourage everyone to try it and provide feedback
> > while
> > > > it is enabled.
> > > >
> > > > So far we identified a few things (and fix them) that made it
> > borderline
> > > > unusable (bug in workflow for UI-only changes, GitHub starting to
> > 429-us
> > > > with too many requests, and the mysterious "hanging" of the latest
> > > > botocore/celery (?) "special tests" -> all that is already addressed
> in
> > > > main, and those issues should not happen (hopefully), so I'd say we
> can
> > > now
> > > > "truly" see how it might work.
> > > >
> > > > And one comment from my side - indeed, I find it nice actually, but
> > it's
> > > > definitely not a "deal breaker"- so if others find it too
> disruptive, I
> > > am
> > > > definitely not going to die on this hill, I just thought it does
> > improve
> > > > the workflow in the way that it allows for mostly "fire and forget"
> > when
> > > > you approve the workflow, one thing that it definitely improves is
> that
> > > you
> > > > do not have to remember about coming back to merge a request when CI
> > > > succeeds.
> > > >
> > > > J.
> > > >
> > > > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <ka...@gmail.com>
> > wrote:
> > > >
> > > >> Forgot to note an additional point in Summary: If we find anything
> > > blocking
> > > >> us in that period, we will merge
> > > >> https://github.com/apache/airflow/pull/50009 to disable auto-merge.
> > > >>
> > > >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <ka...@gmail.com>
> wrote:
> > > >>
> > > >>> Jarek & I discussed it on Slack in #internal-airflow-ci-cd. Summary
> > > >> below:
> > > >>> I have a PR to disable it:
> > > https://github.com/apache/airflow/pull/50009.
> > > >>> However, given that many countries will be on holiday on May 1 due
> to
> > > >>> Labour Day, and some teething issues were fixed yesterday, we will
> > let
> > > it
> > > >>> run for a few more days so other committers and contributors can
> get
> > a
> > > >>> chance to try it out and share their experience after the
> > > >> experiment/trial
> > > >>> is concluded.
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <ka...@gmail.com>
> > wrote:
> > > >>>
> > > >>>> Whoops yeah.
> > > >>>>
> > > >>>>> Yep. Because it did not have all conversations resolved. We also
> > have
> > > >>>> "require resolved conversation" as one of the branch protection
> > > >>>> conditions.
> > > >>>> I resolved the conversation and it got merged automatically.
> > > >>>>
> > > >>>> Let's adapt it when ready though, I don't see any urgency of
> getting
> > > >>>> enabling auto-merge or getting it contributed immediately to asf
> > INFRA
> > > >> when
> > > >>>> it isn't critical. It is about priortization
> > > >>>>
> > > >>>> I'd say - if that is really bothering us - let's shape the feature
> > > >> rather
> > > >>>>> than outright reject it.
> > > >>>>
> > > >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <ja...@potiuk.com>
> > wrote:
> > > >>>>
> > > >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <ka...@gmail.com>
> > > >> wrote:
> > > >>>>>> To the point that the original PR is still not merged even
> after I
> > > >> had
> > > >>>>>> re-triggered the failed tests yesterday:
> > > >>>>>> https://github.com/apache/airflow/pull/49727
> > > >>>>>>
> > > >>>>>>
> > > >>>>> Yep. Because it did not have all conversations resolved. We also
> > have
> > > >>>>> "require resolved conversation" as one of the branch protection
> > > >>>>> conditions.
> > > >>>>> I resolved the conversation and it got merged automatically.
> > > >>>>>
> > > >>>>>
> > > >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <ka...@gmail.com>
> > > >> wrote:
> > > >>>>>>> The gitbox escape hatch isn't it though -- if we are to allow
> > that
> > > >>>>> why
> > > >>>>>> not
> > > >>>>>>> just allow people to merge it directly from github that to go
> via
> > > >> an
> > > >>>>>>> "escape hatch".
> > > >>>>> Generally speaking GitHub has this option. Currently "admins"
> have
> > a
> > > >>>>> possibility of overriding branch protection (via UI). And it
> would
> > be
> > > >>>>> possible - if INFRA will allow it - to possibly add an .asf.yaml
> > > >> feature
> > > >>>>> to
> > > >>>>> also allow branch protection override for all committers or a
> > subset
> > > of
> > > >>>>> the
> > > >>>>> committers (PMC Members ? ). This is more of a limitation of the
> > > >> current
> > > >>>>> implementation of permissions than a missing feature. If we all
> > feel
> > > >> that
> > > >>>>> the gitbox escape hatch is not enough, we can likely even
> > contribute
> > > >>>>> such a
> > > >>>>> feature to .asf.yaml - if INFRA will be ok with the option. It's
> > very
> > > >>>>> easy
> > > >>>>> to contribute to - INFRA made it possible, we have a new
> framework:
> > > >>>>> https://github.com/apache/infrastructure-asfyaml - we can even
> > > >> implement
> > > >>>>> "airflow-only" .asf.yaml feature, that will not be initially
> > > available
> > > >> to
> > > >>>>> other ASF projects and later we can promote it to be available to
> > > >>>>> everyone.
> > > >>>>>
> > > >>>>> I'd say - if that is really bothering us - let's shape the
> feature
> > > >> rather
> > > >>>>> than outright reject it.
> > > >>>>>
> > > >>>>>
> > > >>>>>>> I am -1 on this auto-merge feature
> > > >>>>>>>
> > > >>>>> Understood :). But let's give it a bit more time as well and
> maybe
> > > >>>>> improve
> > > >>>>> it (see above) - unless we really feel we are blocked now - then
> it
> > > >>>>> should
> > > >>>>> be as easy as merging an .asf.yaml change to disable it.
> > > >>>>>
> > > >>>>>
> > > >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <ka...@gmail.com>
> > > >>>>> wrote:
> > > >>>>>>>> That’s not a single person, it impacts the committers and the
> PR
> > > >>>>> author
> > > >>>>>>>> involved too. I don’t see how team productivity soars here.
> > > >>>>>>>>
> > > >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com>
> > > >>>>> wrote:
> > > >>>>>>>>> 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 <
> > jarek@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 <
> > > >> kaxilnaik@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 <
> jarek@potiuk.com
> > >
> > > >>>>>> wrote:
> > > >>>>>>>>>>>> On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <
> > > >>>>> eladkal@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,
> > > >>>>>>>>>>>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > > For additional commands, e-mail: dev-help@airflow.apache.org
> > >
> > >
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

I really like Jens's line of thought. Rather than focusing on the negative
side, try to figure out a way to make it work :). That's very inspiring.

I think the original slack proposal of Jens was rather brittle, but it made
me think that we can actually implement what we need rather quickly.

Following the `Dependabot` style @rebase - we could implement - very easily
- there are ready actions for that and other projects like apache beam are
using similar workflows - the comment workflow, where maintainer who wants
to merge  (or auto-merge) such "failing" PR would just comment it
appropriately.

What we really want is to make the "finalize" check succeed, so if the PR
misses the "Finalize" step, a committer would just have to comment it with
"@bypass-finalize` or `@finalize` or similar. And what it would do, it
would use Github API to make the "Finalize" check succeed. There is an API
for that.

That has a few nice properties:

* it uses the same GitHub UI we use, no need to have an "escape hatch" and
separate remote
* it follows the pattern we already agreed to some time ago and generally
follow -> we are supposed (as maintainers) to explain when we are merging
such failing PR to show that this is a deliberate action - I usually for
example always add "fixed already in main" or "Fixed already by #..."
comment - you really need a comment in this case explaining that it was not
accidental "merge".
* so if we have such workflow, it would "force" maintainer to make a
deliberate decision "yes I want to merge it despite failing" and make a
comment in the PR
* it would only set the "finalize" check to succeed, so still you would not
be able to merge it without having an approval - this would only bypass the
"finalize" check

WDYT? Would that address all concerns with auto-merge ? Does it make sense
and is it "easy enough" to follow? Or are there any other concerns?




On Wed, Apr 30, 2025 at 10:36 PM Pavankumar Gopidesu <
gopidesupavan@gmail.com> wrote:

> I am also in line with Jens. The auto-merge feature works well in keeping
> the CI pipeline green before merging.
> However, there are situations where we need to merge changes quickly.
> Instead of using an
> escape route (which I’m not a fan of, as it carries risks if something goes
> wrong—even though we can revert, it’s still a concern),
> we could explore ways to dynamically bypass certain checks when necessary
> or maybe some help from INFRA?
>
> Pavan
>
> On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler <j_scheffler@gmx.de.invalid
> >
> wrote:
>
> > As there was a call for more opinions. Here I am :-D
> >
> > I understand both positions. As I like AutoMerge very much I am not
> > giving up :-D I'd like to keep it.
> >
> > I think there is still an option in between. Maybe need to draft a bit
> > of thoughts but I think we could build something still around the
> > limitations allowing automation.
> >
> > Added a minor thought to the slack chat. But if community rules propose
> > to push to devchennel let me know.
> >
> > Jens
> >
> > On 30.04.25 11:04, Jarek Potiuk wrote:
> > > Yeah, And I would encourage everyone to try it and provide feedback
> while
> > > it is enabled.
> > >
> > > So far we identified a few things (and fix them) that made it
> borderline
> > > unusable (bug in workflow for UI-only changes, GitHub starting to
> 429-us
> > > with too many requests, and the mysterious "hanging" of the latest
> > > botocore/celery (?) "special tests" -> all that is already addressed in
> > > main, and those issues should not happen (hopefully), so I'd say we can
> > now
> > > "truly" see how it might work.
> > >
> > > And one comment from my side - indeed, I find it nice actually, but
> it's
> > > definitely not a "deal breaker"- so if others find it too disruptive, I
> > am
> > > definitely not going to die on this hill, I just thought it does
> improve
> > > the workflow in the way that it allows for mostly "fire and forget"
> when
> > > you approve the workflow, one thing that it definitely improves is that
> > you
> > > do not have to remember about coming back to merge a request when CI
> > > succeeds.
> > >
> > > J.
> > >
> > > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <ka...@gmail.com>
> wrote:
> > >
> > >> Forgot to note an additional point in Summary: If we find anything
> > blocking
> > >> us in that period, we will merge
> > >> https://github.com/apache/airflow/pull/50009 to disable auto-merge.
> > >>
> > >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <ka...@gmail.com> wrote:
> > >>
> > >>> Jarek & I discussed it on Slack in #internal-airflow-ci-cd. Summary
> > >> below:
> > >>> I have a PR to disable it:
> > https://github.com/apache/airflow/pull/50009.
> > >>> However, given that many countries will be on holiday on May 1 due to
> > >>> Labour Day, and some teething issues were fixed yesterday, we will
> let
> > it
> > >>> run for a few more days so other committers and contributors can get
> a
> > >>> chance to try it out and share their experience after the
> > >> experiment/trial
> > >>> is concluded.
> > >>>
> > >>>
> > >>>
> > >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <ka...@gmail.com>
> wrote:
> > >>>
> > >>>> Whoops yeah.
> > >>>>
> > >>>>> Yep. Because it did not have all conversations resolved. We also
> have
> > >>>> "require resolved conversation" as one of the branch protection
> > >>>> conditions.
> > >>>> I resolved the conversation and it got merged automatically.
> > >>>>
> > >>>> Let's adapt it when ready though, I don't see any urgency of getting
> > >>>> enabling auto-merge or getting it contributed immediately to asf
> INFRA
> > >> when
> > >>>> it isn't critical. It is about priortization
> > >>>>
> > >>>> I'd say - if that is really bothering us - let's shape the feature
> > >> rather
> > >>>>> than outright reject it.
> > >>>>
> > >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <ja...@potiuk.com>
> wrote:
> > >>>>
> > >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <ka...@gmail.com>
> > >> wrote:
> > >>>>>> To the point that the original PR is still not merged even after I
> > >> had
> > >>>>>> re-triggered the failed tests yesterday:
> > >>>>>> https://github.com/apache/airflow/pull/49727
> > >>>>>>
> > >>>>>>
> > >>>>> Yep. Because it did not have all conversations resolved. We also
> have
> > >>>>> "require resolved conversation" as one of the branch protection
> > >>>>> conditions.
> > >>>>> I resolved the conversation and it got merged automatically.
> > >>>>>
> > >>>>>
> > >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <ka...@gmail.com>
> > >> wrote:
> > >>>>>>> The gitbox escape hatch isn't it though -- if we are to allow
> that
> > >>>>> why
> > >>>>>> not
> > >>>>>>> just allow people to merge it directly from github that to go via
> > >> an
> > >>>>>>> "escape hatch".
> > >>>>> Generally speaking GitHub has this option. Currently "admins" have
> a
> > >>>>> possibility of overriding branch protection (via UI). And it would
> be
> > >>>>> possible - if INFRA will allow it - to possibly add an .asf.yaml
> > >> feature
> > >>>>> to
> > >>>>> also allow branch protection override for all committers or a
> subset
> > of
> > >>>>> the
> > >>>>> committers (PMC Members ? ). This is more of a limitation of the
> > >> current
> > >>>>> implementation of permissions than a missing feature. If we all
> feel
> > >> that
> > >>>>> the gitbox escape hatch is not enough, we can likely even
> contribute
> > >>>>> such a
> > >>>>> feature to .asf.yaml - if INFRA will be ok with the option. It's
> very
> > >>>>> easy
> > >>>>> to contribute to - INFRA made it possible, we have a new framework:
> > >>>>> https://github.com/apache/infrastructure-asfyaml - we can even
> > >> implement
> > >>>>> "airflow-only" .asf.yaml feature, that will not be initially
> > available
> > >> to
> > >>>>> other ASF projects and later we can promote it to be available to
> > >>>>> everyone.
> > >>>>>
> > >>>>> I'd say - if that is really bothering us - let's shape the feature
> > >> rather
> > >>>>> than outright reject it.
> > >>>>>
> > >>>>>
> > >>>>>>> I am -1 on this auto-merge feature
> > >>>>>>>
> > >>>>> Understood :). But let's give it a bit more time as well and maybe
> > >>>>> improve
> > >>>>> it (see above) - unless we really feel we are blocked now - then it
> > >>>>> should
> > >>>>> be as easy as merging an .asf.yaml change to disable it.
> > >>>>>
> > >>>>>
> > >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <ka...@gmail.com>
> > >>>>> wrote:
> > >>>>>>>> That’s not a single person, it impacts the committers and the PR
> > >>>>> author
> > >>>>>>>> involved too. I don’t see how team productivity soars here.
> > >>>>>>>>
> > >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com>
> > >>>>> wrote:
> > >>>>>>>>> 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 <
> jarek@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 <
> > >> kaxilnaik@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 <jarek@potiuk.com
> >
> > >>>>>> wrote:
> > >>>>>>>>>>>> On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <
> > >>>>> eladkal@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,
> > >>>>>>>>>>>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > For additional commands, e-mail: dev-help@airflow.apache.org
> >
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Pavankumar Gopidesu <go...@gmail.com>]

I am also in line with Jens. The auto-merge feature works well in keeping
the CI pipeline green before merging.
However, there are situations where we need to merge changes quickly.
Instead of using an
escape route (which I’m not a fan of, as it carries risks if something goes
wrong—even though we can revert, it’s still a concern),
we could explore ways to dynamically bypass certain checks when necessary
or maybe some help from INFRA?

Pavan

On Wed, Apr 30, 2025 at 9:22 PM Jens Scheffler <j_...@gmx.de.invalid>
wrote:

> As there was a call for more opinions. Here I am :-D
>
> I understand both positions. As I like AutoMerge very much I am not
> giving up :-D I'd like to keep it.
>
> I think there is still an option in between. Maybe need to draft a bit
> of thoughts but I think we could build something still around the
> limitations allowing automation.
>
> Added a minor thought to the slack chat. But if community rules propose
> to push to devchennel let me know.
>
> Jens
>
> On 30.04.25 11:04, Jarek Potiuk wrote:
> > Yeah, And I would encourage everyone to try it and provide feedback while
> > it is enabled.
> >
> > So far we identified a few things (and fix them) that made it borderline
> > unusable (bug in workflow for UI-only changes, GitHub starting to 429-us
> > with too many requests, and the mysterious "hanging" of the latest
> > botocore/celery (?) "special tests" -> all that is already addressed in
> > main, and those issues should not happen (hopefully), so I'd say we can
> now
> > "truly" see how it might work.
> >
> > And one comment from my side - indeed, I find it nice actually, but it's
> > definitely not a "deal breaker"- so if others find it too disruptive, I
> am
> > definitely not going to die on this hill, I just thought it does improve
> > the workflow in the way that it allows for mostly "fire and forget" when
> > you approve the workflow, one thing that it definitely improves is that
> you
> > do not have to remember about coming back to merge a request when CI
> > succeeds.
> >
> > J.
> >
> > On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <ka...@gmail.com> wrote:
> >
> >> Forgot to note an additional point in Summary: If we find anything
> blocking
> >> us in that period, we will merge
> >> https://github.com/apache/airflow/pull/50009 to disable auto-merge.
> >>
> >> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <ka...@gmail.com> wrote:
> >>
> >>> Jarek & I discussed it on Slack in #internal-airflow-ci-cd. Summary
> >> below:
> >>> I have a PR to disable it:
> https://github.com/apache/airflow/pull/50009.
> >>> However, given that many countries will be on holiday on May 1 due to
> >>> Labour Day, and some teething issues were fixed yesterday, we will let
> it
> >>> run for a few more days so other committers and contributors can get a
> >>> chance to try it out and share their experience after the
> >> experiment/trial
> >>> is concluded.
> >>>
> >>>
> >>>
> >>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <ka...@gmail.com> wrote:
> >>>
> >>>> Whoops yeah.
> >>>>
> >>>>> Yep. Because it did not have all conversations resolved. We also have
> >>>> "require resolved conversation" as one of the branch protection
> >>>> conditions.
> >>>> I resolved the conversation and it got merged automatically.
> >>>>
> >>>> Let's adapt it when ready though, I don't see any urgency of getting
> >>>> enabling auto-merge or getting it contributed immediately to asf INFRA
> >> when
> >>>> it isn't critical. It is about priortization
> >>>>
> >>>> I'd say - if that is really bothering us - let's shape the feature
> >> rather
> >>>>> than outright reject it.
> >>>>
> >>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <ja...@potiuk.com> wrote:
> >>>>
> >>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <ka...@gmail.com>
> >> wrote:
> >>>>>> To the point that the original PR is still not merged even after I
> >> had
> >>>>>> re-triggered the failed tests yesterday:
> >>>>>> https://github.com/apache/airflow/pull/49727
> >>>>>>
> >>>>>>
> >>>>> Yep. Because it did not have all conversations resolved. We also have
> >>>>> "require resolved conversation" as one of the branch protection
> >>>>> conditions.
> >>>>> I resolved the conversation and it got merged automatically.
> >>>>>
> >>>>>
> >>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <ka...@gmail.com>
> >> wrote:
> >>>>>>> The gitbox escape hatch isn't it though -- if we are to allow that
> >>>>> why
> >>>>>> not
> >>>>>>> just allow people to merge it directly from github that to go via
> >> an
> >>>>>>> "escape hatch".
> >>>>> Generally speaking GitHub has this option. Currently "admins" have a
> >>>>> possibility of overriding branch protection (via UI). And it would be
> >>>>> possible - if INFRA will allow it - to possibly add an .asf.yaml
> >> feature
> >>>>> to
> >>>>> also allow branch protection override for all committers or a subset
> of
> >>>>> the
> >>>>> committers (PMC Members ? ). This is more of a limitation of the
> >> current
> >>>>> implementation of permissions than a missing feature. If we all feel
> >> that
> >>>>> the gitbox escape hatch is not enough, we can likely even contribute
> >>>>> such a
> >>>>> feature to .asf.yaml - if INFRA will be ok with the option. It's very
> >>>>> easy
> >>>>> to contribute to - INFRA made it possible, we have a new framework:
> >>>>> https://github.com/apache/infrastructure-asfyaml - we can even
> >> implement
> >>>>> "airflow-only" .asf.yaml feature, that will not be initially
> available
> >> to
> >>>>> other ASF projects and later we can promote it to be available to
> >>>>> everyone.
> >>>>>
> >>>>> I'd say - if that is really bothering us - let's shape the feature
> >> rather
> >>>>> than outright reject it.
> >>>>>
> >>>>>
> >>>>>>> I am -1 on this auto-merge feature
> >>>>>>>
> >>>>> Understood :). But let's give it a bit more time as well and maybe
> >>>>> improve
> >>>>> it (see above) - unless we really feel we are blocked now - then it
> >>>>> should
> >>>>> be as easy as merging an .asf.yaml change to disable it.
> >>>>>
> >>>>>
> >>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <ka...@gmail.com>
> >>>>> wrote:
> >>>>>>>> That’s not a single person, it impacts the committers and the PR
> >>>>> author
> >>>>>>>> involved too. I don’t see how team productivity soars here.
> >>>>>>>>
> >>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com>
> >>>>> wrote:
> >>>>>>>>> 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 <
> >> kaxilnaik@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 <
> >>>>> eladkal@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,
> >>>>>>>>>>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> For additional commands, e-mail: dev-help@airflow.apache.org
>
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jens Scheffler <j_...@gmx.de.INVALID>]

As there was a call for more opinions. Here I am :-D

I understand both positions. As I like AutoMerge very much I am not 
giving up :-D I'd like to keep it.

I think there is still an option in between. Maybe need to draft a bit 
of thoughts but I think we could build something still around the 
limitations allowing automation.

Added a minor thought to the slack chat. But if community rules propose 
to push to devchennel let me know.

Jens

On 30.04.25 11:04, Jarek Potiuk wrote:
> Yeah, And I would encourage everyone to try it and provide feedback while
> it is enabled.
>
> So far we identified a few things (and fix them) that made it borderline
> unusable (bug in workflow for UI-only changes, GitHub starting to 429-us
> with too many requests, and the mysterious "hanging" of the latest
> botocore/celery (?) "special tests" -> all that is already addressed in
> main, and those issues should not happen (hopefully), so I'd say we can now
> "truly" see how it might work.
>
> And one comment from my side - indeed, I find it nice actually, but it's
> definitely not a "deal breaker"- so if others find it too disruptive, I am
> definitely not going to die on this hill, I just thought it does improve
> the workflow in the way that it allows for mostly "fire and forget" when
> you approve the workflow, one thing that it definitely improves is that you
> do not have to remember about coming back to merge a request when CI
> succeeds.
>
> J.
>
> On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <ka...@gmail.com> wrote:
>
>> Forgot to note an additional point in Summary: If we find anything blocking
>> us in that period, we will merge
>> https://github.com/apache/airflow/pull/50009 to disable auto-merge.
>>
>> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <ka...@gmail.com> wrote:
>>
>>> Jarek & I discussed it on Slack in #internal-airflow-ci-cd. Summary
>> below:
>>> I have a PR to disable it: https://github.com/apache/airflow/pull/50009.
>>> However, given that many countries will be on holiday on May 1 due to
>>> Labour Day, and some teething issues were fixed yesterday, we will let it
>>> run for a few more days so other committers and contributors can get a
>>> chance to try it out and share their experience after the
>> experiment/trial
>>> is concluded.
>>>
>>>
>>>
>>> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <ka...@gmail.com> wrote:
>>>
>>>> Whoops yeah.
>>>>
>>>>> Yep. Because it did not have all conversations resolved. We also have
>>>> "require resolved conversation" as one of the branch protection
>>>> conditions.
>>>> I resolved the conversation and it got merged automatically.
>>>>
>>>> Let's adapt it when ready though, I don't see any urgency of getting
>>>> enabling auto-merge or getting it contributed immediately to asf INFRA
>> when
>>>> it isn't critical. It is about priortization
>>>>
>>>> I'd say - if that is really bothering us - let's shape the feature
>> rather
>>>>> than outright reject it.
>>>>
>>>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <ja...@potiuk.com> wrote:
>>>>
>>>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <ka...@gmail.com>
>> wrote:
>>>>>> To the point that the original PR is still not merged even after I
>> had
>>>>>> re-triggered the failed tests yesterday:
>>>>>> https://github.com/apache/airflow/pull/49727
>>>>>>
>>>>>>
>>>>> Yep. Because it did not have all conversations resolved. We also have
>>>>> "require resolved conversation" as one of the branch protection
>>>>> conditions.
>>>>> I resolved the conversation and it got merged automatically.
>>>>>
>>>>>
>>>>>> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <ka...@gmail.com>
>> wrote:
>>>>>>> The gitbox escape hatch isn't it though -- if we are to allow that
>>>>> why
>>>>>> not
>>>>>>> just allow people to merge it directly from github that to go via
>> an
>>>>>>> "escape hatch".
>>>>> Generally speaking GitHub has this option. Currently "admins" have a
>>>>> possibility of overriding branch protection (via UI). And it would be
>>>>> possible - if INFRA will allow it - to possibly add an .asf.yaml
>> feature
>>>>> to
>>>>> also allow branch protection override for all committers or a subset of
>>>>> the
>>>>> committers (PMC Members ? ). This is more of a limitation of the
>> current
>>>>> implementation of permissions than a missing feature. If we all feel
>> that
>>>>> the gitbox escape hatch is not enough, we can likely even contribute
>>>>> such a
>>>>> feature to .asf.yaml - if INFRA will be ok with the option. It's very
>>>>> easy
>>>>> to contribute to - INFRA made it possible, we have a new framework:
>>>>> https://github.com/apache/infrastructure-asfyaml - we can even
>> implement
>>>>> "airflow-only" .asf.yaml feature, that will not be initially available
>> to
>>>>> other ASF projects and later we can promote it to be available to
>>>>> everyone.
>>>>>
>>>>> I'd say - if that is really bothering us - let's shape the feature
>> rather
>>>>> than outright reject it.
>>>>>
>>>>>
>>>>>>> I am -1 on this auto-merge feature
>>>>>>>
>>>>> Understood :). But let's give it a bit more time as well and maybe
>>>>> improve
>>>>> it (see above) - unless we really feel we are blocked now - then it
>>>>> should
>>>>> be as easy as merging an .asf.yaml change to disable it.
>>>>>
>>>>>
>>>>>>> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <ka...@gmail.com>
>>>>> wrote:
>>>>>>>> That’s not a single person, it impacts the committers and the PR
>>>>> author
>>>>>>>> involved too. I don’t see how team productivity soars here.
>>>>>>>>
>>>>>>>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com>
>>>>> wrote:
>>>>>>>>> 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 <
>> kaxilnaik@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 <
>>>>> eladkal@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,
>>>>>>>>>>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

Yeah, And I would encourage everyone to try it and provide feedback while
it is enabled.

So far we identified a few things (and fix them) that made it borderline
unusable (bug in workflow for UI-only changes, GitHub starting to 429-us
with too many requests, and the mysterious "hanging" of the latest
botocore/celery (?) "special tests" -> all that is already addressed in
main, and those issues should not happen (hopefully), so I'd say we can now
"truly" see how it might work.

And one comment from my side - indeed, I find it nice actually, but it's
definitely not a "deal breaker"- so if others find it too disruptive, I am
definitely not going to die on this hill, I just thought it does improve
the workflow in the way that it allows for mostly "fire and forget" when
you approve the workflow, one thing that it definitely improves is that you
do not have to remember about coming back to merge a request when CI
succeeds.

J.

On Wed, Apr 30, 2025 at 10:58 AM Kaxil Naik <ka...@gmail.com> wrote:

> Forgot to note an additional point in Summary: If we find anything blocking
> us in that period, we will merge
> https://github.com/apache/airflow/pull/50009 to disable auto-merge.
>
> On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <ka...@gmail.com> wrote:
>
> > Jarek & I discussed it on Slack in #internal-airflow-ci-cd. Summary
> below:
> >
> > I have a PR to disable it: https://github.com/apache/airflow/pull/50009.
> > However, given that many countries will be on holiday on May 1 due to
> > Labour Day, and some teething issues were fixed yesterday, we will let it
> > run for a few more days so other committers and contributors can get a
> > chance to try it out and share their experience after the
> experiment/trial
> > is concluded.
> >
> >
> >
> > On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <ka...@gmail.com> wrote:
> >
> >> Whoops yeah.
> >>
> >> >Yep. Because it did not have all conversations resolved. We also have
> >> "require resolved conversation" as one of the branch protection
> >> conditions.
> >> I resolved the conversation and it got merged automatically.
> >>
> >> Let's adapt it when ready though, I don't see any urgency of getting
> >> enabling auto-merge or getting it contributed immediately to asf INFRA
> when
> >> it isn't critical. It is about priortization
> >>
> >> I'd say - if that is really bothering us - let's shape the feature
> rather
> >>> than outright reject it.
> >>
> >>
> >> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <ja...@potiuk.com> wrote:
> >>
> >>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <ka...@gmail.com>
> wrote:
> >>>
> >>> > To the point that the original PR is still not merged even after I
> had
> >>> > re-triggered the failed tests yesterday:
> >>> > https://github.com/apache/airflow/pull/49727
> >>> >
> >>> >
> >>> Yep. Because it did not have all conversations resolved. We also have
> >>> "require resolved conversation" as one of the branch protection
> >>> conditions.
> >>> I resolved the conversation and it got merged automatically.
> >>>
> >>>
> >>> >
> >>> > On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <ka...@gmail.com>
> wrote:
> >>> >
> >>> > > The gitbox escape hatch isn't it though -- if we are to allow that
> >>> why
> >>> > not
> >>> > > just allow people to merge it directly from github that to go via
> an
> >>> > > "escape hatch".
> >>> >
> >>>
> >>> Generally speaking GitHub has this option. Currently "admins" have a
> >>> possibility of overriding branch protection (via UI). And it would be
> >>> possible - if INFRA will allow it - to possibly add an .asf.yaml
> feature
> >>> to
> >>> also allow branch protection override for all committers or a subset of
> >>> the
> >>> committers (PMC Members ? ). This is more of a limitation of the
> current
> >>> implementation of permissions than a missing feature. If we all feel
> that
> >>> the gitbox escape hatch is not enough, we can likely even contribute
> >>> such a
> >>> feature to .asf.yaml - if INFRA will be ok with the option. It's very
> >>> easy
> >>> to contribute to - INFRA made it possible, we have a new framework:
> >>> https://github.com/apache/infrastructure-asfyaml - we can even
> implement
> >>> "airflow-only" .asf.yaml feature, that will not be initially available
> to
> >>> other ASF projects and later we can promote it to be available to
> >>> everyone.
> >>>
> >>> I'd say - if that is really bothering us - let's shape the feature
> rather
> >>> than outright reject it.
> >>>
> >>>
> >>> > > I am -1 on this auto-merge feature
> >>> > >
> >>> >
> >>>
> >>> Understood :). But let's give it a bit more time as well and maybe
> >>> improve
> >>> it (see above) - unless we really feel we are blocked now - then it
> >>> should
> >>> be as easy as merging an .asf.yaml change to disable it.
> >>>
> >>>
> >>> > >
> >>> > > On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <ka...@gmail.com>
> >>> wrote:
> >>> > >
> >>> > >> That’s not a single person, it impacts the committers and the PR
> >>> author
> >>> > >> involved too. I don’t see how team productivity soars here.
> >>> > >>
> >>> > >> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com>
> >>> wrote:
> >>> > >>
> >>> > >>> 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 <
> kaxilnaik@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 <
> >>> eladkal@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,
> >>> > >>> >> >
> >>> > >>> >>
> >>> > >>> >
> >>> > >>>
> >>> > >>
> >>> >
> >>>
> >>
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

Forgot to note an additional point in Summary: If we find anything blocking
us in that period, we will merge
https://github.com/apache/airflow/pull/50009 to disable auto-merge.

On Wed, 30 Apr 2025 at 14:26, Kaxil Naik <ka...@gmail.com> wrote:

> Jarek & I discussed it on Slack in #internal-airflow-ci-cd. Summary below:
>
> I have a PR to disable it: https://github.com/apache/airflow/pull/50009.
> However, given that many countries will be on holiday on May 1 due to
> Labour Day, and some teething issues were fixed yesterday, we will let it
> run for a few more days so other committers and contributors can get a
> chance to try it out and share their experience after the experiment/trial
> is concluded.
>
>
>
> On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <ka...@gmail.com> wrote:
>
>> Whoops yeah.
>>
>> >Yep. Because it did not have all conversations resolved. We also have
>> "require resolved conversation" as one of the branch protection
>> conditions.
>> I resolved the conversation and it got merged automatically.
>>
>> Let's adapt it when ready though, I don't see any urgency of getting
>> enabling auto-merge or getting it contributed immediately to asf INFRA when
>> it isn't critical. It is about priortization
>>
>> I'd say - if that is really bothering us - let's shape the feature rather
>>> than outright reject it.
>>
>>
>> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <ja...@potiuk.com> wrote:
>>
>>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <ka...@gmail.com> wrote:
>>>
>>> > To the point that the original PR is still not merged even after I had
>>> > re-triggered the failed tests yesterday:
>>> > https://github.com/apache/airflow/pull/49727
>>> >
>>> >
>>> Yep. Because it did not have all conversations resolved. We also have
>>> "require resolved conversation" as one of the branch protection
>>> conditions.
>>> I resolved the conversation and it got merged automatically.
>>>
>>>
>>> >
>>> > On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <ka...@gmail.com> wrote:
>>> >
>>> > > The gitbox escape hatch isn't it though -- if we are to allow that
>>> why
>>> > not
>>> > > just allow people to merge it directly from github that to go via an
>>> > > "escape hatch".
>>> >
>>>
>>> Generally speaking GitHub has this option. Currently "admins" have a
>>> possibility of overriding branch protection (via UI). And it would be
>>> possible - if INFRA will allow it - to possibly add an .asf.yaml feature
>>> to
>>> also allow branch protection override for all committers or a subset of
>>> the
>>> committers (PMC Members ? ). This is more of a limitation of the current
>>> implementation of permissions than a missing feature. If we all feel that
>>> the gitbox escape hatch is not enough, we can likely even contribute
>>> such a
>>> feature to .asf.yaml - if INFRA will be ok with the option. It's very
>>> easy
>>> to contribute to - INFRA made it possible, we have a new framework:
>>> https://github.com/apache/infrastructure-asfyaml - we can even implement
>>> "airflow-only" .asf.yaml feature, that will not be initially available to
>>> other ASF projects and later we can promote it to be available to
>>> everyone.
>>>
>>> I'd say - if that is really bothering us - let's shape the feature rather
>>> than outright reject it.
>>>
>>>
>>> > > I am -1 on this auto-merge feature
>>> > >
>>> >
>>>
>>> Understood :). But let's give it a bit more time as well and maybe
>>> improve
>>> it (see above) - unless we really feel we are blocked now - then it
>>> should
>>> be as easy as merging an .asf.yaml change to disable it.
>>>
>>>
>>> > >
>>> > > On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <ka...@gmail.com>
>>> wrote:
>>> > >
>>> > >> That’s not a single person, it impacts the committers and the PR
>>> author
>>> > >> involved too. I don’t see how team productivity soars here.
>>> > >>
>>> > >> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com>
>>> wrote:
>>> > >>
>>> > >>> 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 <ka...@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 <
>>> eladkal@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,
>>> > >>> >> >
>>> > >>> >>
>>> > >>> >
>>> > >>>
>>> > >>
>>> >
>>>
>>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

Jarek & I discussed it on Slack in #internal-airflow-ci-cd. Summary below:

I have a PR to disable it: https://github.com/apache/airflow/pull/50009.
However, given that many countries will be on holiday on May 1 due to
Labour Day, and some teething issues were fixed yesterday, we will let it
run for a few more days so other committers and contributors can get a
chance to try it out and share their experience after the experiment/trial
is concluded.



On Wed, 30 Apr 2025 at 13:59, Kaxil Naik <ka...@gmail.com> wrote:

> Whoops yeah.
>
> >Yep. Because it did not have all conversations resolved. We also have
> "require resolved conversation" as one of the branch protection conditions.
> I resolved the conversation and it got merged automatically.
>
> Let's adapt it when ready though, I don't see any urgency of getting
> enabling auto-merge or getting it contributed immediately to asf INFRA when
> it isn't critical. It is about priortization
>
> I'd say - if that is really bothering us - let's shape the feature rather
>> than outright reject it.
>
>
> On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <ka...@gmail.com> wrote:
>>
>> > To the point that the original PR is still not merged even after I had
>> > re-triggered the failed tests yesterday:
>> > https://github.com/apache/airflow/pull/49727
>> >
>> >
>> Yep. Because it did not have all conversations resolved. We also have
>> "require resolved conversation" as one of the branch protection
>> conditions.
>> I resolved the conversation and it got merged automatically.
>>
>>
>> >
>> > On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <ka...@gmail.com> wrote:
>> >
>> > > The gitbox escape hatch isn't it though -- if we are to allow that why
>> > not
>> > > just allow people to merge it directly from github that to go via an
>> > > "escape hatch".
>> >
>>
>> Generally speaking GitHub has this option. Currently "admins" have a
>> possibility of overriding branch protection (via UI). And it would be
>> possible - if INFRA will allow it - to possibly add an .asf.yaml feature
>> to
>> also allow branch protection override for all committers or a subset of
>> the
>> committers (PMC Members ? ). This is more of a limitation of the current
>> implementation of permissions than a missing feature. If we all feel that
>> the gitbox escape hatch is not enough, we can likely even contribute such
>> a
>> feature to .asf.yaml - if INFRA will be ok with the option. It's very easy
>> to contribute to - INFRA made it possible, we have a new framework:
>> https://github.com/apache/infrastructure-asfyaml - we can even implement
>> "airflow-only" .asf.yaml feature, that will not be initially available to
>> other ASF projects and later we can promote it to be available to
>> everyone.
>>
>> I'd say - if that is really bothering us - let's shape the feature rather
>> than outright reject it.
>>
>>
>> > > I am -1 on this auto-merge feature
>> > >
>> >
>>
>> Understood :). But let's give it a bit more time as well and maybe improve
>> it (see above) - unless we really feel we are blocked now - then it should
>> be as easy as merging an .asf.yaml change to disable it.
>>
>>
>> > >
>> > > On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <ka...@gmail.com> wrote:
>> > >
>> > >> That’s not a single person, it impacts the committers and the PR
>> author
>> > >> involved too. I don’t see how team productivity soars here.
>> > >>
>> > >> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com> wrote:
>> > >>
>> > >>> 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 <ka...@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 <eladkal@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,
>> > >>> >> >
>> > >>> >>
>> > >>> >
>> > >>>
>> > >>
>> >
>>
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

Whoops yeah.

>Yep. Because it did not have all conversations resolved. We also have
"require resolved conversation" as one of the branch protection conditions.
I resolved the conversation and it got merged automatically.

Let's adapt it when ready though, I don't see any urgency of getting
enabling auto-merge or getting it contributed immediately to asf INFRA when
it isn't critical. It is about priortization

I'd say - if that is really bothering us - let's shape the feature rather
> than outright reject it.


On Wed, 30 Apr 2025 at 12:37, Jarek Potiuk <ja...@potiuk.com> wrote:

> On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <ka...@gmail.com> wrote:
>
> > To the point that the original PR is still not merged even after I had
> > re-triggered the failed tests yesterday:
> > https://github.com/apache/airflow/pull/49727
> >
> >
> Yep. Because it did not have all conversations resolved. We also have
> "require resolved conversation" as one of the branch protection conditions.
> I resolved the conversation and it got merged automatically.
>
>
> >
> > On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <ka...@gmail.com> wrote:
> >
> > > The gitbox escape hatch isn't it though -- if we are to allow that why
> > not
> > > just allow people to merge it directly from github that to go via an
> > > "escape hatch".
> >
>
> Generally speaking GitHub has this option. Currently "admins" have a
> possibility of overriding branch protection (via UI). And it would be
> possible - if INFRA will allow it - to possibly add an .asf.yaml feature to
> also allow branch protection override for all committers or a subset of the
> committers (PMC Members ? ). This is more of a limitation of the current
> implementation of permissions than a missing feature. If we all feel that
> the gitbox escape hatch is not enough, we can likely even contribute such a
> feature to .asf.yaml - if INFRA will be ok with the option. It's very easy
> to contribute to - INFRA made it possible, we have a new framework:
> https://github.com/apache/infrastructure-asfyaml - we can even implement
> "airflow-only" .asf.yaml feature, that will not be initially available to
> other ASF projects and later we can promote it to be available to everyone.
>
> I'd say - if that is really bothering us - let's shape the feature rather
> than outright reject it.
>
>
> > > I am -1 on this auto-merge feature
> > >
> >
>
> Understood :). But let's give it a bit more time as well and maybe improve
> it (see above) - unless we really feel we are blocked now - then it should
> be as easy as merging an .asf.yaml change to disable it.
>
>
> > >
> > > On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <ka...@gmail.com> wrote:
> > >
> > >> That’s not a single person, it impacts the committers and the PR
> author
> > >> involved too. I don’t see how team productivity soars here.
> > >>
> > >> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com> wrote:
> > >>
> > >>> 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 <ka...@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 <el...@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,
> > >>> >> >
> > >>> >>
> > >>> >
> > >>>
> > >>
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik <ka...@gmail.com> wrote:

> To the point that the original PR is still not merged even after I had
> re-triggered the failed tests yesterday:
> https://github.com/apache/airflow/pull/49727
>
>
Yep. Because it did not have all conversations resolved. We also have
"require resolved conversation" as one of the branch protection conditions.
I resolved the conversation and it got merged automatically.


>
> On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <ka...@gmail.com> wrote:
>
> > The gitbox escape hatch isn't it though -- if we are to allow that why
> not
> > just allow people to merge it directly from github that to go via an
> > "escape hatch".
>

Generally speaking GitHub has this option. Currently "admins" have a
possibility of overriding branch protection (via UI). And it would be
possible - if INFRA will allow it - to possibly add an .asf.yaml feature to
also allow branch protection override for all committers or a subset of the
committers (PMC Members ? ). This is more of a limitation of the current
implementation of permissions than a missing feature. If we all feel that
the gitbox escape hatch is not enough, we can likely even contribute such a
feature to .asf.yaml - if INFRA will be ok with the option. It's very easy
to contribute to - INFRA made it possible, we have a new framework:
https://github.com/apache/infrastructure-asfyaml - we can even implement
"airflow-only" .asf.yaml feature, that will not be initially available to
other ASF projects and later we can promote it to be available to everyone.

I'd say - if that is really bothering us - let's shape the feature rather
than outright reject it.


> > I am -1 on this auto-merge feature
> >
>

Understood :). But let's give it a bit more time as well and maybe improve
it (see above) - unless we really feel we are blocked now - then it should
be as easy as merging an .asf.yaml change to disable it.


> >
> > On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <ka...@gmail.com> wrote:
> >
> >> That’s not a single person, it impacts the committers and the PR author
> >> involved too. I don’t see how team productivity soars here.
> >>
> >> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com> wrote:
> >>
> >>> 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 <ka...@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 <el...@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,
> >>> >> >
> >>> >>
> >>> >
> >>>
> >>
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

To the point that the original PR is still not merged even after I had
re-triggered the failed tests yesterday:
https://github.com/apache/airflow/pull/49727



On Wed, 30 Apr 2025 at 11:20, Kaxil Naik <ka...@gmail.com> wrote:

> The gitbox escape hatch isn't it though -- if we are to allow that why not
> just allow people to merge it directly from github that to go via an
> "escape hatch".
>
> I am -1 on this auto-merge feature
>
>
> On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <ka...@gmail.com> wrote:
>
>> That’s not a single person, it impacts the committers and the PR author
>> involved too. I don’t see how team productivity soars here.
>>
>> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com> wrote:
>>
>>> 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 <ka...@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 <el...@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,
>>> >> >
>>> >>
>>> >
>>>
>>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

The gitbox escape hatch isn't it though -- if we are to allow that why not
just allow people to merge it directly from github that to go via an
"escape hatch".

I am -1 on this auto-merge feature


On Wed, 30 Apr 2025 at 11:18, Kaxil Naik <ka...@gmail.com> wrote:

> That’s not a single person, it impacts the committers and the PR author
> involved too. I don’t see how team productivity soars here.
>
> On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com> wrote:
>
>> 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 <ka...@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 <el...@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,
>> >> >
>> >>
>> >
>>
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

That’s not a single person, it impacts the committers and the PR author
involved too. I don’t see how team productivity soars here.

On Wed, 30 Apr 2025 at 02:39, Jarek Potiuk <ja...@potiuk.com> wrote:

> 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 <ka...@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 <el...@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,
> >> >
> >>
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

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 <ka...@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 <el...@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,
>> >
>>
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

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 <ka...@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 <el...@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,
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Kaxil Naik <ka...@gmail.com>]

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 <el...@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,
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

On Tue, Apr 29, 2025 at 1:46 PM Elad Kalif <el...@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,

Re: [DISCUSS} Enabled experiment auto-merge feature

[Elad Kalif <el...@apache.org>]

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.


On Tue, Apr 29, 2025 at 6:18 AM Amogh Desai <am...@gmail.com>
wrote:

> I gave it another try and I am convinced that it is helpful now.
>
> >  (if we enable it for v3-0-test) - potentially we could disable the
> "draft" option for backport PRs  - even if workflows are not going to be
> started those backport PRs will have this "required status check" that will
> prevent accidental merges and we will have to rebase/update/close/reopen to
> retrigger the workflow.
>
> I like this :)
>
> > new contributors that have PRS where workflow are waiting for approval
>
> And this too, I have seen some new contributor PRs go stale, this will
> solve that issue.
>
> Thanks & Regards,
> Amogh Desai
>
>
> On Sun, Apr 27, 2025 at 5:35 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > BTW. The nice side-effect of it is that with this "required" check, we
> > should not have any problems any more with merging PRs that had:
> >
> > * bug in workflow resulting in no workflow run at ll
> > * new contributors that have PRS where workflow are waiting for approval
> > * (if we enable it for v3-0-test) - potentially we could disable the
> > "draft" option for backport PRs  - even if workflows are not going to be
> > started those backport PRs will have this "required status check" that
> will
> > prevent accidental merges and we will have to rebase/update/close/reopen
> to
> > retrigger the workflow.
> >
> > In all those cases the required status check will prevent the PR from
> being
> > merged accidentally.
> >
> > J.
> >
> >
> > On Sun, Apr 27, 2025 at 4:41 AM Amogh Desai <am...@gmail.com>
> > wrote:
> >
> > > > That was a temporary issue - it is green now. I needed to figure out
> > how
> > > to
> > > name checks properly, and it turned out that "Tests / Finalize tests /
> > > Summarize Warnings" is named (for whatever reason) as "Finalize tests /
> > > Summarize Warnings" when run as part of the composite "umbrella"
> workflow
> > > "Tests".  Simply - the first level path is stripped in this case.
> > >
> > > Oh ok!
> > >
> > > > So I struggled a bit with guessing how it should be done. But I
> figured
> > > it
> > > - out - your PR is green now, and if you see it as a required check -
> > > re-running the finalize warning or just rebasing your PR should do the
> > job.
> > > It was only really problematic for PRs that were completing in a last
> > hour
> > > or two where I tried to figure out what check I should put in.... And
> > >
> > > Haha, I see. Unfortunately that was the case with one of my PRs :)
> > > Gave me the initial bad preview.
> > >
> > >
> > > My initial experience was shadowing the benefits that this would offer
> to
> > > the mental
> > > load of maintainers. It would be a great tool overall as Jens mentioned
> > > too.
> > >
> > > However, I am going to try it out again and express any concerns once i
> > > encounter
> > > them. IAC, it's worth experimenting with, given that our recent
> > experiments
> > > like
> > > backport tool, dosubot have all stayed :D
> > >
> > >
> > > Thanks & Regards,
> > > Amogh Desai
> > >
> > >
> > > On Sat, Apr 26, 2025 at 9:35 PM Jens Scheffler
> > <j_scheffler@gmx.de.invalid
> > > >
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > thanks for tuning on auto-merge.
> > > >
> > > > Agree that there might be a residual risk that pipeline goes green
> "too
> > > > early" and approval is there... but I think we need to use carefully.
> > > >
> > > > I just did my first auto merge and carefully watched... all looks
> good.
> > > > If it helps in only 50% of cases to reduce mental load I am totally
> > > > fine. Might not be perfect in all situations. But in cases where (1)
> I
> > > > trust the author that while I am not watching nothing surprising is
> > > > committed and turning green and (2) pipeline is stable. Otherwise
> there
> > > > is always the "resert PR" option.
> > > >
> > > > Jens
> > > >
> > > > P.S.: Ups, found one dependency issue which I attempt to fix in
> #49827
> > > >
> > > > On 26.04.25 15:45, Jarek Potiuk wrote:
> > > > > On Sat, Apr 26, 2025 at 3:02 PM Amogh Desai <
> > amoghdesai.oss@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> I am not sure if I like this feature a lot with my recent
> experience
> > > > with
> > > > >> this PR: https://github.com/apache/airflow/pull/49692.
> > > > >>
> > > > >> On the PR status, it mentions "finalize tests" is waiting to
> report
> > > > status
> > > > >> but when i describe the tests, I see that task has completed.
> > > > >
> > > > >> It is quite confusing to me with this experience at least. But,
> > maybe
> > > I
> > > > >> need some getting used to.
> > > > >>
> > > > > That was a temporary issue - it is green now. I needed to figure
> out
> > > how
> > > > to
> > > > > name checks properly, and it turned out that "Tests / Finalize
> tests
> > /
> > > > > Summarize Warnings" is named (for whatever reason) as "Finalize
> > tests /
> > > > > Summarize Warnings" when run as part of the composite "umbrella"
> > > workflow
> > > > > "Tests".  Simply - the first level path is stripped in this case.
> > > > >
> > > > > And yes it took me some time because indeed -  it inconsistently
> > shows
> > > in
> > > > > the UI and it depends on timing:
> > > > >
> > > > > * When you add it first as required, it is displayed as  "Finalize
> > > tests
> > > > /
> > > > > Summarize Warnings" but when the job starts running this required
> > check
> > > > > magically turns into "Tests / Finalize tests / Summarize Warnings"
> > > > > * Also this required check disappears when you remove it (and PR
> can
> > be
> > > > > merged then) but when you add it to existing PR, it will not get
> > green
> > > > > until you rerun the job (or whole PR)  - so if your "Summarize
> > > Warnings"
> > > > > was added before I properly added the check - you will see two
> > > different
> > > > > checks - one completed (With Tests) and one waiting (without).
> > > > >
> > > > > . ¯\_(ツ)_/¯
> > > > >
> > > > > So I struggled a bit with guessing how it should be done. But I
> > figured
> > > > it
> > > > > - out - your PR is green now, and if you see it as a required
> check -
> > > > > re-running the finalize warning or just rebasing your PR should do
> > the
> > > > job.
> > > > > It was only really problematic for PRs that were completing in a
> last
> > > > hour
> > > > > or two where I tried to figure out what check I should put in....
> And
> > > > >
> > > > > For the fun of it, I added the log of me fighting with GH naming at
> > the
> > > > end
> > > > > of that email:
> > > > >
> > > > >
> > > > >> Speaking from a general perspective and in time sensitive
> situations
> > > > like
> > > > >> cutting an RC, I am sure
> > > > >> we would like to have some PRs in as and when they pass CI /
> > sometimes
> > > > >> don't pass (known CI issues going on).
> > > > >>
> > > > > Yeah. That's the biggest worry I have. Those are the mitigations we
> > can
> > > > > apply:
> > > > >
> > > > > a) temporarily disable branch protection when we are in "crunch"
> > > > situation
> > > > > b) push such PRs directly to gitbox - bypassing GH branch
> protection
> > > > >
> > > > >
> > > > >> This will make it slightly inconvenient and hard to keep track of
> > > > whether a
> > > > >> PR has been merged or not, at the very least.
> > > > >>
> > > > > Yes, when we push it directly we have to make sure to do it
> carefully
> > > and
> > > > > add PR# manually
> > > > >
> > > > >> I'm expressing this concern because I do not see any option to
> > > > "override"
> > > > >> the enable or disable automerge feature and merge
> > > > >> it myself.
> > > > >>
> > > > >>
> > > > > Yes. There is none.
> > > > >
> > > > >
> > > > >> Would love it if someone could help me with that information.
> > > > >>
> > > > >> P.S: It could be that I am not able to force merge because someone
> > > else
> > > > >> (Jarek) enabled the force merge for my PR?
> > > > >>
> > > > > Temp timing issue
> > > > >
> > > > >
> > > > >> Thanks & Regards,
> > > > >> Amogh Desai
> > > > >>
> > > > > ------------------------------------------------------------------
> > > > >
> > > > > Lof of fighting with GH naming:
> > > > >
> > > > > commit 4a074c1b17726df4939fb8b426f6cb90b53f0881
> > > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > > Date:   Sat Apr 26 15:12:36 2025 +0200
> > > > >
> > > > >      Another attempt to set the right context
> > > > >
> > > > > commit af977853743a97d5785a9b7f9ce63e7fd91cd133
> > > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > > Date:   Sat Apr 26 14:49:51 2025 +0200
> > > > >
> > > > >      Another attempt to set the right context
> > > > >
> > > > > commit 97c5d9cf33e4c2f0654c744872ca8de452daa5ca
> > > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > > Date:   Sat Apr 26 14:40:45 2025 +0200
> > > > >
> > > > >      Another attempt to set the right context
> > > > >
> > > > > commit 14d60c7ce99f30d3477a01d56dbce15460b11f28
> > > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > > Date:   Sat Apr 26 14:33:05 2025 +0200
> > > > >
> > > > >      Maybe this one will work?
> > > > >
> > > > > commit 156d0e8080c20b5cb61315ac6118cbce5abf75a9
> > > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > > Date:   Sat Apr 26 14:21:51 2025 +0200
> > > > >
> > > > >      Another attempt to set the right context
> > > > >
> > > > > commit 1adf5afcc9cca4a6492359b2883b5348f60e7f9f
> > > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > > Date:   Sat Apr 26 12:56:08 2025 +0200
> > > > >
> > > > >      Proper (?) context for branch protection experiment (#49815)
> > > > >
> > > > >
> > > > >
> > > > >> On Sat, Apr 26, 2025 at 5:41 PM Jarek Potiuk <ja...@potiuk.com>
> > > wrote:
> > > > >>
> > > > >>> Hello everyone,
> > > > >>>
> > > > >>> With some initial teething problems we've enabled an
> "experimental"
> > > > >> feature
> > > > >>> of "auto-merging" PRs in our repo. It should potentially help
> with
> > > > >> "focus"
> > > > >>> of maintainers, because they will not have to come-back to the
> PRs
> > to
> > > > >> merge
> > > > >>> it once they enabled auto-merge for them.
> > > > >>>
> > > > >>> It works in the way, that when "required status checks",
> "reviews"
> > > and
> > > > >>> "resolved conversations" (the required conditions for "main"
> > > protected
> > > > >>> branch) are not met, committer can use "Enable auto-merge" on the
> > PR
> > > > and
> > > > >>> when all conditions are met, the PR will get merged
> automatically.
> > > > >>>
> > > > >>> But after enabling it, it turns out that this has one **serious**
> > > > >> drawback.
> > > > >>> We currently cannot override the protection from GitHub UI, and
> > it's
> > > > not
> > > > >>> possible to merge PR that did not pass one of the checks (So
> > > "Finalize
> > > > >>> tests / Summarize warnings" has to complete successfully in order
> > to
> > > be
> > > > >>> able to merge PR,
> > > > >>>
> > > > >>> This is quite a bit of a blocker. But not entirely, because I've
> > > > learned
> > > > >> (I
> > > > >>> did not know it before) that we (committers) already have a way
> to
> > > > bypass
> > > > >>> ANY protection - by directly pushing code to main branch via
> gitbox
> > > URL
> > > > >>> exposed by Apache Infrastructure:
> > > > >>>
> > > > >>> https://gitbox.apache.org/repos/asf
> > > > >>>
> > > > >>> Specifically - you can set this as remote
> > > > >>> https://gitbox.apache.org/repos/asf/airflow.git - and push
> changes
> > > > >>> directly
> > > > >>> to "main" branch. It will bypass any protection. You do not even
> > need
> > > > to
> > > > >>> get a review from another maintainer (yes - I just tested it and
> it
> > > > >> works).
> > > > >>> You just need to authenticate with your apache id / password.
> > > > >>>
> > > > >>> That is not great from a security and provenance point of view,
> but
> > > > well,
> > > > >>> ASF allows it for now (which is something we will have to fix
> > > > eventually
> > > > >> I
> > > > >>> think.  It requires using git CLI/local client to push such
> > branches
> > > > and
> > > > >>> there are some small things we have to remember (like manually
> > adding
> > > > PR
> > > > >> #
> > > > >>> to the branch we are pushing or not having PR# in the merged
> commit
> > > at
> > > > >>> all).
> > > > >>>
> > > > >>> Certainly not as convenient as the merge button in PR - but
> > workable
> > > if
> > > > >> we
> > > > >>> want to merge something quickly, regardless of the status (and
> > > > apparently
> > > > >>> regardless of review / approval which is a bummer).
> > > > >>>
> > > > >>> I  left it enabled for a moment - the weekend maximum and maybe
> > > > beginning
> > > > >>> of Monday and would love to hear what you think.
> > > > >>>
> > > > >>> J.
> > > > >>>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > > > For additional commands, e-mail: dev-help@airflow.apache.org
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Amogh Desai <am...@gmail.com>]

I gave it another try and I am convinced that it is helpful now.

>  (if we enable it for v3-0-test) - potentially we could disable the
"draft" option for backport PRs  - even if workflows are not going to be
started those backport PRs will have this "required status check" that will
prevent accidental merges and we will have to rebase/update/close/reopen to
retrigger the workflow.

I like this :)

> new contributors that have PRS where workflow are waiting for approval

And this too, I have seen some new contributor PRs go stale, this will
solve that issue.

Thanks & Regards,
Amogh Desai


On Sun, Apr 27, 2025 at 5:35 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> BTW. The nice side-effect of it is that with this "required" check, we
> should not have any problems any more with merging PRs that had:
>
> * bug in workflow resulting in no workflow run at ll
> * new contributors that have PRS where workflow are waiting for approval
> * (if we enable it for v3-0-test) - potentially we could disable the
> "draft" option for backport PRs  - even if workflows are not going to be
> started those backport PRs will have this "required status check" that will
> prevent accidental merges and we will have to rebase/update/close/reopen to
> retrigger the workflow.
>
> In all those cases the required status check will prevent the PR from being
> merged accidentally.
>
> J.
>
>
> On Sun, Apr 27, 2025 at 4:41 AM Amogh Desai <am...@gmail.com>
> wrote:
>
> > > That was a temporary issue - it is green now. I needed to figure out
> how
> > to
> > name checks properly, and it turned out that "Tests / Finalize tests /
> > Summarize Warnings" is named (for whatever reason) as "Finalize tests /
> > Summarize Warnings" when run as part of the composite "umbrella" workflow
> > "Tests".  Simply - the first level path is stripped in this case.
> >
> > Oh ok!
> >
> > > So I struggled a bit with guessing how it should be done. But I figured
> > it
> > - out - your PR is green now, and if you see it as a required check -
> > re-running the finalize warning or just rebasing your PR should do the
> job.
> > It was only really problematic for PRs that were completing in a last
> hour
> > or two where I tried to figure out what check I should put in.... And
> >
> > Haha, I see. Unfortunately that was the case with one of my PRs :)
> > Gave me the initial bad preview.
> >
> >
> > My initial experience was shadowing the benefits that this would offer to
> > the mental
> > load of maintainers. It would be a great tool overall as Jens mentioned
> > too.
> >
> > However, I am going to try it out again and express any concerns once i
> > encounter
> > them. IAC, it's worth experimenting with, given that our recent
> experiments
> > like
> > backport tool, dosubot have all stayed :D
> >
> >
> > Thanks & Regards,
> > Amogh Desai
> >
> >
> > On Sat, Apr 26, 2025 at 9:35 PM Jens Scheffler
> <j_scheffler@gmx.de.invalid
> > >
> > wrote:
> >
> > > Hi all,
> > >
> > > thanks for tuning on auto-merge.
> > >
> > > Agree that there might be a residual risk that pipeline goes green "too
> > > early" and approval is there... but I think we need to use carefully.
> > >
> > > I just did my first auto merge and carefully watched... all looks good.
> > > If it helps in only 50% of cases to reduce mental load I am totally
> > > fine. Might not be perfect in all situations. But in cases where (1) I
> > > trust the author that while I am not watching nothing surprising is
> > > committed and turning green and (2) pipeline is stable. Otherwise there
> > > is always the "resert PR" option.
> > >
> > > Jens
> > >
> > > P.S.: Ups, found one dependency issue which I attempt to fix in #49827
> > >
> > > On 26.04.25 15:45, Jarek Potiuk wrote:
> > > > On Sat, Apr 26, 2025 at 3:02 PM Amogh Desai <
> amoghdesai.oss@gmail.com>
> > > > wrote:
> > > >
> > > >> I am not sure if I like this feature a lot with my recent experience
> > > with
> > > >> this PR: https://github.com/apache/airflow/pull/49692.
> > > >>
> > > >> On the PR status, it mentions "finalize tests" is waiting to report
> > > status
> > > >> but when i describe the tests, I see that task has completed.
> > > >
> > > >> It is quite confusing to me with this experience at least. But,
> maybe
> > I
> > > >> need some getting used to.
> > > >>
> > > > That was a temporary issue - it is green now. I needed to figure out
> > how
> > > to
> > > > name checks properly, and it turned out that "Tests / Finalize tests
> /
> > > > Summarize Warnings" is named (for whatever reason) as "Finalize
> tests /
> > > > Summarize Warnings" when run as part of the composite "umbrella"
> > workflow
> > > > "Tests".  Simply - the first level path is stripped in this case.
> > > >
> > > > And yes it took me some time because indeed -  it inconsistently
> shows
> > in
> > > > the UI and it depends on timing:
> > > >
> > > > * When you add it first as required, it is displayed as  "Finalize
> > tests
> > > /
> > > > Summarize Warnings" but when the job starts running this required
> check
> > > > magically turns into "Tests / Finalize tests / Summarize Warnings"
> > > > * Also this required check disappears when you remove it (and PR can
> be
> > > > merged then) but when you add it to existing PR, it will not get
> green
> > > > until you rerun the job (or whole PR)  - so if your "Summarize
> > Warnings"
> > > > was added before I properly added the check - you will see two
> > different
> > > > checks - one completed (With Tests) and one waiting (without).
> > > >
> > > > . ¯\_(ツ)_/¯
> > > >
> > > > So I struggled a bit with guessing how it should be done. But I
> figured
> > > it
> > > > - out - your PR is green now, and if you see it as a required check -
> > > > re-running the finalize warning or just rebasing your PR should do
> the
> > > job.
> > > > It was only really problematic for PRs that were completing in a last
> > > hour
> > > > or two where I tried to figure out what check I should put in.... And
> > > >
> > > > For the fun of it, I added the log of me fighting with GH naming at
> the
> > > end
> > > > of that email:
> > > >
> > > >
> > > >> Speaking from a general perspective and in time sensitive situations
> > > like
> > > >> cutting an RC, I am sure
> > > >> we would like to have some PRs in as and when they pass CI /
> sometimes
> > > >> don't pass (known CI issues going on).
> > > >>
> > > > Yeah. That's the biggest worry I have. Those are the mitigations we
> can
> > > > apply:
> > > >
> > > > a) temporarily disable branch protection when we are in "crunch"
> > > situation
> > > > b) push such PRs directly to gitbox - bypassing GH branch protection
> > > >
> > > >
> > > >> This will make it slightly inconvenient and hard to keep track of
> > > whether a
> > > >> PR has been merged or not, at the very least.
> > > >>
> > > > Yes, when we push it directly we have to make sure to do it carefully
> > and
> > > > add PR# manually
> > > >
> > > >> I'm expressing this concern because I do not see any option to
> > > "override"
> > > >> the enable or disable automerge feature and merge
> > > >> it myself.
> > > >>
> > > >>
> > > > Yes. There is none.
> > > >
> > > >
> > > >> Would love it if someone could help me with that information.
> > > >>
> > > >> P.S: It could be that I am not able to force merge because someone
> > else
> > > >> (Jarek) enabled the force merge for my PR?
> > > >>
> > > > Temp timing issue
> > > >
> > > >
> > > >> Thanks & Regards,
> > > >> Amogh Desai
> > > >>
> > > > ------------------------------------------------------------------
> > > >
> > > > Lof of fighting with GH naming:
> > > >
> > > > commit 4a074c1b17726df4939fb8b426f6cb90b53f0881
> > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > Date:   Sat Apr 26 15:12:36 2025 +0200
> > > >
> > > >      Another attempt to set the right context
> > > >
> > > > commit af977853743a97d5785a9b7f9ce63e7fd91cd133
> > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > Date:   Sat Apr 26 14:49:51 2025 +0200
> > > >
> > > >      Another attempt to set the right context
> > > >
> > > > commit 97c5d9cf33e4c2f0654c744872ca8de452daa5ca
> > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > Date:   Sat Apr 26 14:40:45 2025 +0200
> > > >
> > > >      Another attempt to set the right context
> > > >
> > > > commit 14d60c7ce99f30d3477a01d56dbce15460b11f28
> > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > Date:   Sat Apr 26 14:33:05 2025 +0200
> > > >
> > > >      Maybe this one will work?
> > > >
> > > > commit 156d0e8080c20b5cb61315ac6118cbce5abf75a9
> > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > Date:   Sat Apr 26 14:21:51 2025 +0200
> > > >
> > > >      Another attempt to set the right context
> > > >
> > > > commit 1adf5afcc9cca4a6492359b2883b5348f60e7f9f
> > > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > > Date:   Sat Apr 26 12:56:08 2025 +0200
> > > >
> > > >      Proper (?) context for branch protection experiment (#49815)
> > > >
> > > >
> > > >
> > > >> On Sat, Apr 26, 2025 at 5:41 PM Jarek Potiuk <ja...@potiuk.com>
> > wrote:
> > > >>
> > > >>> Hello everyone,
> > > >>>
> > > >>> With some initial teething problems we've enabled an "experimental"
> > > >> feature
> > > >>> of "auto-merging" PRs in our repo. It should potentially help with
> > > >> "focus"
> > > >>> of maintainers, because they will not have to come-back to the PRs
> to
> > > >> merge
> > > >>> it once they enabled auto-merge for them.
> > > >>>
> > > >>> It works in the way, that when "required status checks", "reviews"
> > and
> > > >>> "resolved conversations" (the required conditions for "main"
> > protected
> > > >>> branch) are not met, committer can use "Enable auto-merge" on the
> PR
> > > and
> > > >>> when all conditions are met, the PR will get merged automatically.
> > > >>>
> > > >>> But after enabling it, it turns out that this has one **serious**
> > > >> drawback.
> > > >>> We currently cannot override the protection from GitHub UI, and
> it's
> > > not
> > > >>> possible to merge PR that did not pass one of the checks (So
> > "Finalize
> > > >>> tests / Summarize warnings" has to complete successfully in order
> to
> > be
> > > >>> able to merge PR,
> > > >>>
> > > >>> This is quite a bit of a blocker. But not entirely, because I've
> > > learned
> > > >> (I
> > > >>> did not know it before) that we (committers) already have a way to
> > > bypass
> > > >>> ANY protection - by directly pushing code to main branch via gitbox
> > URL
> > > >>> exposed by Apache Infrastructure:
> > > >>>
> > > >>> https://gitbox.apache.org/repos/asf
> > > >>>
> > > >>> Specifically - you can set this as remote
> > > >>> https://gitbox.apache.org/repos/asf/airflow.git - and push changes
> > > >>> directly
> > > >>> to "main" branch. It will bypass any protection. You do not even
> need
> > > to
> > > >>> get a review from another maintainer (yes - I just tested it and it
> > > >> works).
> > > >>> You just need to authenticate with your apache id / password.
> > > >>>
> > > >>> That is not great from a security and provenance point of view, but
> > > well,
> > > >>> ASF allows it for now (which is something we will have to fix
> > > eventually
> > > >> I
> > > >>> think.  It requires using git CLI/local client to push such
> branches
> > > and
> > > >>> there are some small things we have to remember (like manually
> adding
> > > PR
> > > >> #
> > > >>> to the branch we are pushing or not having PR# in the merged commit
> > at
> > > >>> all).
> > > >>>
> > > >>> Certainly not as convenient as the merge button in PR - but
> workable
> > if
> > > >> we
> > > >>> want to merge something quickly, regardless of the status (and
> > > apparently
> > > >>> regardless of review / approval which is a bummer).
> > > >>>
> > > >>> I  left it enabled for a moment - the weekend maximum and maybe
> > > beginning
> > > >>> of Monday and would love to hear what you think.
> > > >>>
> > > >>> J.
> > > >>>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > > For additional commands, e-mail: dev-help@airflow.apache.org
> > >
> > >
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

BTW. The nice side-effect of it is that with this "required" check, we
should not have any problems any more with merging PRs that had:

* bug in workflow resulting in no workflow run at ll
* new contributors that have PRS where workflow are waiting for approval
* (if we enable it for v3-0-test) - potentially we could disable the
"draft" option for backport PRs  - even if workflows are not going to be
started those backport PRs will have this "required status check" that will
prevent accidental merges and we will have to rebase/update/close/reopen to
retrigger the workflow.

In all those cases the required status check will prevent the PR from being
merged accidentally.

J.


On Sun, Apr 27, 2025 at 4:41 AM Amogh Desai <am...@gmail.com>
wrote:

> > That was a temporary issue - it is green now. I needed to figure out how
> to
> name checks properly, and it turned out that "Tests / Finalize tests /
> Summarize Warnings" is named (for whatever reason) as "Finalize tests /
> Summarize Warnings" when run as part of the composite "umbrella" workflow
> "Tests".  Simply - the first level path is stripped in this case.
>
> Oh ok!
>
> > So I struggled a bit with guessing how it should be done. But I figured
> it
> - out - your PR is green now, and if you see it as a required check -
> re-running the finalize warning or just rebasing your PR should do the job.
> It was only really problematic for PRs that were completing in a last hour
> or two where I tried to figure out what check I should put in.... And
>
> Haha, I see. Unfortunately that was the case with one of my PRs :)
> Gave me the initial bad preview.
>
>
> My initial experience was shadowing the benefits that this would offer to
> the mental
> load of maintainers. It would be a great tool overall as Jens mentioned
> too.
>
> However, I am going to try it out again and express any concerns once i
> encounter
> them. IAC, it's worth experimenting with, given that our recent experiments
> like
> backport tool, dosubot have all stayed :D
>
>
> Thanks & Regards,
> Amogh Desai
>
>
> On Sat, Apr 26, 2025 at 9:35 PM Jens Scheffler <j_scheffler@gmx.de.invalid
> >
> wrote:
>
> > Hi all,
> >
> > thanks for tuning on auto-merge.
> >
> > Agree that there might be a residual risk that pipeline goes green "too
> > early" and approval is there... but I think we need to use carefully.
> >
> > I just did my first auto merge and carefully watched... all looks good.
> > If it helps in only 50% of cases to reduce mental load I am totally
> > fine. Might not be perfect in all situations. But in cases where (1) I
> > trust the author that while I am not watching nothing surprising is
> > committed and turning green and (2) pipeline is stable. Otherwise there
> > is always the "resert PR" option.
> >
> > Jens
> >
> > P.S.: Ups, found one dependency issue which I attempt to fix in #49827
> >
> > On 26.04.25 15:45, Jarek Potiuk wrote:
> > > On Sat, Apr 26, 2025 at 3:02 PM Amogh Desai <am...@gmail.com>
> > > wrote:
> > >
> > >> I am not sure if I like this feature a lot with my recent experience
> > with
> > >> this PR: https://github.com/apache/airflow/pull/49692.
> > >>
> > >> On the PR status, it mentions "finalize tests" is waiting to report
> > status
> > >> but when i describe the tests, I see that task has completed.
> > >
> > >> It is quite confusing to me with this experience at least. But, maybe
> I
> > >> need some getting used to.
> > >>
> > > That was a temporary issue - it is green now. I needed to figure out
> how
> > to
> > > name checks properly, and it turned out that "Tests / Finalize tests /
> > > Summarize Warnings" is named (for whatever reason) as "Finalize tests /
> > > Summarize Warnings" when run as part of the composite "umbrella"
> workflow
> > > "Tests".  Simply - the first level path is stripped in this case.
> > >
> > > And yes it took me some time because indeed -  it inconsistently shows
> in
> > > the UI and it depends on timing:
> > >
> > > * When you add it first as required, it is displayed as  "Finalize
> tests
> > /
> > > Summarize Warnings" but when the job starts running this required check
> > > magically turns into "Tests / Finalize tests / Summarize Warnings"
> > > * Also this required check disappears when you remove it (and PR can be
> > > merged then) but when you add it to existing PR, it will not get green
> > > until you rerun the job (or whole PR)  - so if your "Summarize
> Warnings"
> > > was added before I properly added the check - you will see two
> different
> > > checks - one completed (With Tests) and one waiting (without).
> > >
> > > . ¯\_(ツ)_/¯
> > >
> > > So I struggled a bit with guessing how it should be done. But I figured
> > it
> > > - out - your PR is green now, and if you see it as a required check -
> > > re-running the finalize warning or just rebasing your PR should do the
> > job.
> > > It was only really problematic for PRs that were completing in a last
> > hour
> > > or two where I tried to figure out what check I should put in.... And
> > >
> > > For the fun of it, I added the log of me fighting with GH naming at the
> > end
> > > of that email:
> > >
> > >
> > >> Speaking from a general perspective and in time sensitive situations
> > like
> > >> cutting an RC, I am sure
> > >> we would like to have some PRs in as and when they pass CI / sometimes
> > >> don't pass (known CI issues going on).
> > >>
> > > Yeah. That's the biggest worry I have. Those are the mitigations we can
> > > apply:
> > >
> > > a) temporarily disable branch protection when we are in "crunch"
> > situation
> > > b) push such PRs directly to gitbox - bypassing GH branch protection
> > >
> > >
> > >> This will make it slightly inconvenient and hard to keep track of
> > whether a
> > >> PR has been merged or not, at the very least.
> > >>
> > > Yes, when we push it directly we have to make sure to do it carefully
> and
> > > add PR# manually
> > >
> > >> I'm expressing this concern because I do not see any option to
> > "override"
> > >> the enable or disable automerge feature and merge
> > >> it myself.
> > >>
> > >>
> > > Yes. There is none.
> > >
> > >
> > >> Would love it if someone could help me with that information.
> > >>
> > >> P.S: It could be that I am not able to force merge because someone
> else
> > >> (Jarek) enabled the force merge for my PR?
> > >>
> > > Temp timing issue
> > >
> > >
> > >> Thanks & Regards,
> > >> Amogh Desai
> > >>
> > > ------------------------------------------------------------------
> > >
> > > Lof of fighting with GH naming:
> > >
> > > commit 4a074c1b17726df4939fb8b426f6cb90b53f0881
> > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > Date:   Sat Apr 26 15:12:36 2025 +0200
> > >
> > >      Another attempt to set the right context
> > >
> > > commit af977853743a97d5785a9b7f9ce63e7fd91cd133
> > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > Date:   Sat Apr 26 14:49:51 2025 +0200
> > >
> > >      Another attempt to set the right context
> > >
> > > commit 97c5d9cf33e4c2f0654c744872ca8de452daa5ca
> > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > Date:   Sat Apr 26 14:40:45 2025 +0200
> > >
> > >      Another attempt to set the right context
> > >
> > > commit 14d60c7ce99f30d3477a01d56dbce15460b11f28
> > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > Date:   Sat Apr 26 14:33:05 2025 +0200
> > >
> > >      Maybe this one will work?
> > >
> > > commit 156d0e8080c20b5cb61315ac6118cbce5abf75a9
> > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > Date:   Sat Apr 26 14:21:51 2025 +0200
> > >
> > >      Another attempt to set the right context
> > >
> > > commit 1adf5afcc9cca4a6492359b2883b5348f60e7f9f
> > > Author: Jarek Potiuk <ja...@potiuk.com>
> > > Date:   Sat Apr 26 12:56:08 2025 +0200
> > >
> > >      Proper (?) context for branch protection experiment (#49815)
> > >
> > >
> > >
> > >> On Sat, Apr 26, 2025 at 5:41 PM Jarek Potiuk <ja...@potiuk.com>
> wrote:
> > >>
> > >>> Hello everyone,
> > >>>
> > >>> With some initial teething problems we've enabled an "experimental"
> > >> feature
> > >>> of "auto-merging" PRs in our repo. It should potentially help with
> > >> "focus"
> > >>> of maintainers, because they will not have to come-back to the PRs to
> > >> merge
> > >>> it once they enabled auto-merge for them.
> > >>>
> > >>> It works in the way, that when "required status checks", "reviews"
> and
> > >>> "resolved conversations" (the required conditions for "main"
> protected
> > >>> branch) are not met, committer can use "Enable auto-merge" on the PR
> > and
> > >>> when all conditions are met, the PR will get merged automatically.
> > >>>
> > >>> But after enabling it, it turns out that this has one **serious**
> > >> drawback.
> > >>> We currently cannot override the protection from GitHub UI, and it's
> > not
> > >>> possible to merge PR that did not pass one of the checks (So
> "Finalize
> > >>> tests / Summarize warnings" has to complete successfully in order to
> be
> > >>> able to merge PR,
> > >>>
> > >>> This is quite a bit of a blocker. But not entirely, because I've
> > learned
> > >> (I
> > >>> did not know it before) that we (committers) already have a way to
> > bypass
> > >>> ANY protection - by directly pushing code to main branch via gitbox
> URL
> > >>> exposed by Apache Infrastructure:
> > >>>
> > >>> https://gitbox.apache.org/repos/asf
> > >>>
> > >>> Specifically - you can set this as remote
> > >>> https://gitbox.apache.org/repos/asf/airflow.git - and push changes
> > >>> directly
> > >>> to "main" branch. It will bypass any protection. You do not even need
> > to
> > >>> get a review from another maintainer (yes - I just tested it and it
> > >> works).
> > >>> You just need to authenticate with your apache id / password.
> > >>>
> > >>> That is not great from a security and provenance point of view, but
> > well,
> > >>> ASF allows it for now (which is something we will have to fix
> > eventually
> > >> I
> > >>> think.  It requires using git CLI/local client to push such branches
> > and
> > >>> there are some small things we have to remember (like manually adding
> > PR
> > >> #
> > >>> to the branch we are pushing or not having PR# in the merged commit
> at
> > >>> all).
> > >>>
> > >>> Certainly not as convenient as the merge button in PR - but workable
> if
> > >> we
> > >>> want to merge something quickly, regardless of the status (and
> > apparently
> > >>> regardless of review / approval which is a bummer).
> > >>>
> > >>> I  left it enabled for a moment - the weekend maximum and maybe
> > beginning
> > >>> of Monday and would love to hear what you think.
> > >>>
> > >>> J.
> > >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> > For additional commands, e-mail: dev-help@airflow.apache.org
> >
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Amogh Desai <am...@gmail.com>]

> That was a temporary issue - it is green now. I needed to figure out how
to
name checks properly, and it turned out that "Tests / Finalize tests /
Summarize Warnings" is named (for whatever reason) as "Finalize tests /
Summarize Warnings" when run as part of the composite "umbrella" workflow
"Tests".  Simply - the first level path is stripped in this case.

Oh ok!

> So I struggled a bit with guessing how it should be done. But I figured it
- out - your PR is green now, and if you see it as a required check -
re-running the finalize warning or just rebasing your PR should do the job.
It was only really problematic for PRs that were completing in a last hour
or two where I tried to figure out what check I should put in.... And

Haha, I see. Unfortunately that was the case with one of my PRs :)
Gave me the initial bad preview.


My initial experience was shadowing the benefits that this would offer to
the mental
load of maintainers. It would be a great tool overall as Jens mentioned too.

However, I am going to try it out again and express any concerns once i
encounter
them. IAC, it's worth experimenting with, given that our recent experiments
like
backport tool, dosubot have all stayed :D


Thanks & Regards,
Amogh Desai


On Sat, Apr 26, 2025 at 9:35 PM Jens Scheffler <j_...@gmx.de.invalid>
wrote:

> Hi all,
>
> thanks for tuning on auto-merge.
>
> Agree that there might be a residual risk that pipeline goes green "too
> early" and approval is there... but I think we need to use carefully.
>
> I just did my first auto merge and carefully watched... all looks good.
> If it helps in only 50% of cases to reduce mental load I am totally
> fine. Might not be perfect in all situations. But in cases where (1) I
> trust the author that while I am not watching nothing surprising is
> committed and turning green and (2) pipeline is stable. Otherwise there
> is always the "resert PR" option.
>
> Jens
>
> P.S.: Ups, found one dependency issue which I attempt to fix in #49827
>
> On 26.04.25 15:45, Jarek Potiuk wrote:
> > On Sat, Apr 26, 2025 at 3:02 PM Amogh Desai <am...@gmail.com>
> > wrote:
> >
> >> I am not sure if I like this feature a lot with my recent experience
> with
> >> this PR: https://github.com/apache/airflow/pull/49692.
> >>
> >> On the PR status, it mentions "finalize tests" is waiting to report
> status
> >> but when i describe the tests, I see that task has completed.
> >
> >> It is quite confusing to me with this experience at least. But, maybe I
> >> need some getting used to.
> >>
> > That was a temporary issue - it is green now. I needed to figure out how
> to
> > name checks properly, and it turned out that "Tests / Finalize tests /
> > Summarize Warnings" is named (for whatever reason) as "Finalize tests /
> > Summarize Warnings" when run as part of the composite "umbrella" workflow
> > "Tests".  Simply - the first level path is stripped in this case.
> >
> > And yes it took me some time because indeed -  it inconsistently shows in
> > the UI and it depends on timing:
> >
> > * When you add it first as required, it is displayed as  "Finalize tests
> /
> > Summarize Warnings" but when the job starts running this required check
> > magically turns into "Tests / Finalize tests / Summarize Warnings"
> > * Also this required check disappears when you remove it (and PR can be
> > merged then) but when you add it to existing PR, it will not get green
> > until you rerun the job (or whole PR)  - so if your "Summarize Warnings"
> > was added before I properly added the check - you will see two different
> > checks - one completed (With Tests) and one waiting (without).
> >
> > . ¯\_(ツ)_/¯
> >
> > So I struggled a bit with guessing how it should be done. But I figured
> it
> > - out - your PR is green now, and if you see it as a required check -
> > re-running the finalize warning or just rebasing your PR should do the
> job.
> > It was only really problematic for PRs that were completing in a last
> hour
> > or two where I tried to figure out what check I should put in.... And
> >
> > For the fun of it, I added the log of me fighting with GH naming at the
> end
> > of that email:
> >
> >
> >> Speaking from a general perspective and in time sensitive situations
> like
> >> cutting an RC, I am sure
> >> we would like to have some PRs in as and when they pass CI / sometimes
> >> don't pass (known CI issues going on).
> >>
> > Yeah. That's the biggest worry I have. Those are the mitigations we can
> > apply:
> >
> > a) temporarily disable branch protection when we are in "crunch"
> situation
> > b) push such PRs directly to gitbox - bypassing GH branch protection
> >
> >
> >> This will make it slightly inconvenient and hard to keep track of
> whether a
> >> PR has been merged or not, at the very least.
> >>
> > Yes, when we push it directly we have to make sure to do it carefully and
> > add PR# manually
> >
> >> I'm expressing this concern because I do not see any option to
> "override"
> >> the enable or disable automerge feature and merge
> >> it myself.
> >>
> >>
> > Yes. There is none.
> >
> >
> >> Would love it if someone could help me with that information.
> >>
> >> P.S: It could be that I am not able to force merge because someone else
> >> (Jarek) enabled the force merge for my PR?
> >>
> > Temp timing issue
> >
> >
> >> Thanks & Regards,
> >> Amogh Desai
> >>
> > ------------------------------------------------------------------
> >
> > Lof of fighting with GH naming:
> >
> > commit 4a074c1b17726df4939fb8b426f6cb90b53f0881
> > Author: Jarek Potiuk <ja...@potiuk.com>
> > Date:   Sat Apr 26 15:12:36 2025 +0200
> >
> >      Another attempt to set the right context
> >
> > commit af977853743a97d5785a9b7f9ce63e7fd91cd133
> > Author: Jarek Potiuk <ja...@potiuk.com>
> > Date:   Sat Apr 26 14:49:51 2025 +0200
> >
> >      Another attempt to set the right context
> >
> > commit 97c5d9cf33e4c2f0654c744872ca8de452daa5ca
> > Author: Jarek Potiuk <ja...@potiuk.com>
> > Date:   Sat Apr 26 14:40:45 2025 +0200
> >
> >      Another attempt to set the right context
> >
> > commit 14d60c7ce99f30d3477a01d56dbce15460b11f28
> > Author: Jarek Potiuk <ja...@potiuk.com>
> > Date:   Sat Apr 26 14:33:05 2025 +0200
> >
> >      Maybe this one will work?
> >
> > commit 156d0e8080c20b5cb61315ac6118cbce5abf75a9
> > Author: Jarek Potiuk <ja...@potiuk.com>
> > Date:   Sat Apr 26 14:21:51 2025 +0200
> >
> >      Another attempt to set the right context
> >
> > commit 1adf5afcc9cca4a6492359b2883b5348f60e7f9f
> > Author: Jarek Potiuk <ja...@potiuk.com>
> > Date:   Sat Apr 26 12:56:08 2025 +0200
> >
> >      Proper (?) context for branch protection experiment (#49815)
> >
> >
> >
> >> On Sat, Apr 26, 2025 at 5:41 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> >>
> >>> Hello everyone,
> >>>
> >>> With some initial teething problems we've enabled an "experimental"
> >> feature
> >>> of "auto-merging" PRs in our repo. It should potentially help with
> >> "focus"
> >>> of maintainers, because they will not have to come-back to the PRs to
> >> merge
> >>> it once they enabled auto-merge for them.
> >>>
> >>> It works in the way, that when "required status checks", "reviews" and
> >>> "resolved conversations" (the required conditions for "main" protected
> >>> branch) are not met, committer can use "Enable auto-merge" on the PR
> and
> >>> when all conditions are met, the PR will get merged automatically.
> >>>
> >>> But after enabling it, it turns out that this has one **serious**
> >> drawback.
> >>> We currently cannot override the protection from GitHub UI, and it's
> not
> >>> possible to merge PR that did not pass one of the checks (So "Finalize
> >>> tests / Summarize warnings" has to complete successfully in order to be
> >>> able to merge PR,
> >>>
> >>> This is quite a bit of a blocker. But not entirely, because I've
> learned
> >> (I
> >>> did not know it before) that we (committers) already have a way to
> bypass
> >>> ANY protection - by directly pushing code to main branch via gitbox URL
> >>> exposed by Apache Infrastructure:
> >>>
> >>> https://gitbox.apache.org/repos/asf
> >>>
> >>> Specifically - you can set this as remote
> >>> https://gitbox.apache.org/repos/asf/airflow.git - and push changes
> >>> directly
> >>> to "main" branch. It will bypass any protection. You do not even need
> to
> >>> get a review from another maintainer (yes - I just tested it and it
> >> works).
> >>> You just need to authenticate with your apache id / password.
> >>>
> >>> That is not great from a security and provenance point of view, but
> well,
> >>> ASF allows it for now (which is something we will have to fix
> eventually
> >> I
> >>> think.  It requires using git CLI/local client to push such branches
> and
> >>> there are some small things we have to remember (like manually adding
> PR
> >> #
> >>> to the branch we are pushing or not having PR# in the merged commit at
> >>> all).
> >>>
> >>> Certainly not as convenient as the merge button in PR - but workable if
> >> we
> >>> want to merge something quickly, regardless of the status (and
> apparently
> >>> regardless of review / approval which is a bummer).
> >>>
> >>> I  left it enabled for a moment - the weekend maximum and maybe
> beginning
> >>> of Monday and would love to hear what you think.
> >>>
> >>> J.
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
> For additional commands, e-mail: dev-help@airflow.apache.org
>
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jens Scheffler <j_...@gmx.de.INVALID>]

Hi all,

thanks for tuning on auto-merge.

Agree that there might be a residual risk that pipeline goes green "too 
early" and approval is there... but I think we need to use carefully.

I just did my first auto merge and carefully watched... all looks good. 
If it helps in only 50% of cases to reduce mental load I am totally 
fine. Might not be perfect in all situations. But in cases where (1) I 
trust the author that while I am not watching nothing surprising is 
committed and turning green and (2) pipeline is stable. Otherwise there 
is always the "resert PR" option.

Jens

P.S.: Ups, found one dependency issue which I attempt to fix in #49827

On 26.04.25 15:45, Jarek Potiuk wrote:
> On Sat, Apr 26, 2025 at 3:02 PM Amogh Desai <am...@gmail.com>
> wrote:
>
>> I am not sure if I like this feature a lot with my recent experience with
>> this PR: https://github.com/apache/airflow/pull/49692.
>>
>> On the PR status, it mentions "finalize tests" is waiting to report status
>> but when i describe the tests, I see that task has completed.
>
>> It is quite confusing to me with this experience at least. But, maybe I
>> need some getting used to.
>>
> That was a temporary issue - it is green now. I needed to figure out how to
> name checks properly, and it turned out that "Tests / Finalize tests /
> Summarize Warnings" is named (for whatever reason) as "Finalize tests /
> Summarize Warnings" when run as part of the composite "umbrella" workflow
> "Tests".  Simply - the first level path is stripped in this case.
>
> And yes it took me some time because indeed -  it inconsistently shows in
> the UI and it depends on timing:
>
> * When you add it first as required, it is displayed as  "Finalize tests /
> Summarize Warnings" but when the job starts running this required check
> magically turns into "Tests / Finalize tests / Summarize Warnings"
> * Also this required check disappears when you remove it (and PR can be
> merged then) but when you add it to existing PR, it will not get green
> until you rerun the job (or whole PR)  - so if your "Summarize Warnings"
> was added before I properly added the check - you will see two different
> checks - one completed (With Tests) and one waiting (without).
>
> . ¯\_(ツ)_/¯
>
> So I struggled a bit with guessing how it should be done. But I figured it
> - out - your PR is green now, and if you see it as a required check -
> re-running the finalize warning or just rebasing your PR should do the job.
> It was only really problematic for PRs that were completing in a last hour
> or two where I tried to figure out what check I should put in.... And
>
> For the fun of it, I added the log of me fighting with GH naming at the end
> of that email:
>
>
>> Speaking from a general perspective and in time sensitive situations like
>> cutting an RC, I am sure
>> we would like to have some PRs in as and when they pass CI / sometimes
>> don't pass (known CI issues going on).
>>
> Yeah. That's the biggest worry I have. Those are the mitigations we can
> apply:
>
> a) temporarily disable branch protection when we are in "crunch" situation
> b) push such PRs directly to gitbox - bypassing GH branch protection
>
>
>> This will make it slightly inconvenient and hard to keep track of whether a
>> PR has been merged or not, at the very least.
>>
> Yes, when we push it directly we have to make sure to do it carefully and
> add PR# manually
>
>> I'm expressing this concern because I do not see any option to "override"
>> the enable or disable automerge feature and merge
>> it myself.
>>
>>
> Yes. There is none.
>
>
>> Would love it if someone could help me with that information.
>>
>> P.S: It could be that I am not able to force merge because someone else
>> (Jarek) enabled the force merge for my PR?
>>
> Temp timing issue
>
>
>> Thanks & Regards,
>> Amogh Desai
>>
> ------------------------------------------------------------------
>
> Lof of fighting with GH naming:
>
> commit 4a074c1b17726df4939fb8b426f6cb90b53f0881
> Author: Jarek Potiuk <ja...@potiuk.com>
> Date:   Sat Apr 26 15:12:36 2025 +0200
>
>      Another attempt to set the right context
>
> commit af977853743a97d5785a9b7f9ce63e7fd91cd133
> Author: Jarek Potiuk <ja...@potiuk.com>
> Date:   Sat Apr 26 14:49:51 2025 +0200
>
>      Another attempt to set the right context
>
> commit 97c5d9cf33e4c2f0654c744872ca8de452daa5ca
> Author: Jarek Potiuk <ja...@potiuk.com>
> Date:   Sat Apr 26 14:40:45 2025 +0200
>
>      Another attempt to set the right context
>
> commit 14d60c7ce99f30d3477a01d56dbce15460b11f28
> Author: Jarek Potiuk <ja...@potiuk.com>
> Date:   Sat Apr 26 14:33:05 2025 +0200
>
>      Maybe this one will work?
>
> commit 156d0e8080c20b5cb61315ac6118cbce5abf75a9
> Author: Jarek Potiuk <ja...@potiuk.com>
> Date:   Sat Apr 26 14:21:51 2025 +0200
>
>      Another attempt to set the right context
>
> commit 1adf5afcc9cca4a6492359b2883b5348f60e7f9f
> Author: Jarek Potiuk <ja...@potiuk.com>
> Date:   Sat Apr 26 12:56:08 2025 +0200
>
>      Proper (?) context for branch protection experiment (#49815)
>
>
>
>> On Sat, Apr 26, 2025 at 5:41 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>>
>>> Hello everyone,
>>>
>>> With some initial teething problems we've enabled an "experimental"
>> feature
>>> of "auto-merging" PRs in our repo. It should potentially help with
>> "focus"
>>> of maintainers, because they will not have to come-back to the PRs to
>> merge
>>> it once they enabled auto-merge for them.
>>>
>>> It works in the way, that when "required status checks", "reviews" and
>>> "resolved conversations" (the required conditions for "main" protected
>>> branch) are not met, committer can use "Enable auto-merge" on the PR and
>>> when all conditions are met, the PR will get merged automatically.
>>>
>>> But after enabling it, it turns out that this has one **serious**
>> drawback.
>>> We currently cannot override the protection from GitHub UI, and it's not
>>> possible to merge PR that did not pass one of the checks (So "Finalize
>>> tests / Summarize warnings" has to complete successfully in order to be
>>> able to merge PR,
>>>
>>> This is quite a bit of a blocker. But not entirely, because I've learned
>> (I
>>> did not know it before) that we (committers) already have a way to bypass
>>> ANY protection - by directly pushing code to main branch via gitbox URL
>>> exposed by Apache Infrastructure:
>>>
>>> https://gitbox.apache.org/repos/asf
>>>
>>> Specifically - you can set this as remote
>>> https://gitbox.apache.org/repos/asf/airflow.git - and push changes
>>> directly
>>> to "main" branch. It will bypass any protection. You do not even need to
>>> get a review from another maintainer (yes - I just tested it and it
>> works).
>>> You just need to authenticate with your apache id / password.
>>>
>>> That is not great from a security and provenance point of view, but well,
>>> ASF allows it for now (which is something we will have to fix eventually
>> I
>>> think.  It requires using git CLI/local client to push such branches and
>>> there are some small things we have to remember (like manually adding PR
>> #
>>> to the branch we are pushing or not having PR# in the merged commit at
>>> all).
>>>
>>> Certainly not as convenient as the merge button in PR - but workable if
>> we
>>> want to merge something quickly, regardless of the status (and apparently
>>> regardless of review / approval which is a bummer).
>>>
>>> I  left it enabled for a moment - the weekend maximum and maybe beginning
>>> of Monday and would love to hear what you think.
>>>
>>> J.
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org

Re: [DISCUSS} Enabled experiment auto-merge feature

[Jarek Potiuk <ja...@potiuk.com>]

On Sat, Apr 26, 2025 at 3:02 PM Amogh Desai <am...@gmail.com>
wrote:

> I am not sure if I like this feature a lot with my recent experience with
> this PR: https://github.com/apache/airflow/pull/49692.
>
> On the PR status, it mentions "finalize tests" is waiting to report status
> but when i describe the tests, I see that task has completed.


> It is quite confusing to me with this experience at least. But, maybe I
> need some getting used to.
>

That was a temporary issue - it is green now. I needed to figure out how to
name checks properly, and it turned out that "Tests / Finalize tests /
Summarize Warnings" is named (for whatever reason) as "Finalize tests /
Summarize Warnings" when run as part of the composite "umbrella" workflow
"Tests".  Simply - the first level path is stripped in this case.

And yes it took me some time because indeed -  it inconsistently shows in
the UI and it depends on timing:

* When you add it first as required, it is displayed as  "Finalize tests /
Summarize Warnings" but when the job starts running this required check
magically turns into "Tests / Finalize tests / Summarize Warnings"
* Also this required check disappears when you remove it (and PR can be
merged then) but when you add it to existing PR, it will not get green
until you rerun the job (or whole PR)  - so if your "Summarize Warnings"
was added before I properly added the check - you will see two different
checks - one completed (With Tests) and one waiting (without).

. ¯\_(ツ)_/¯

So I struggled a bit with guessing how it should be done. But I figured it
- out - your PR is green now, and if you see it as a required check -
re-running the finalize warning or just rebasing your PR should do the job.
It was only really problematic for PRs that were completing in a last hour
or two where I tried to figure out what check I should put in.... And

For the fun of it, I added the log of me fighting with GH naming at the end
of that email:


>
> Speaking from a general perspective and in time sensitive situations like
> cutting an RC, I am sure
> we would like to have some PRs in as and when they pass CI / sometimes
> don't pass (known CI issues going on).
>

Yeah. That's the biggest worry I have. Those are the mitigations we can
apply:

a) temporarily disable branch protection when we are in "crunch" situation
b) push such PRs directly to gitbox - bypassing GH branch protection


> This will make it slightly inconvenient and hard to keep track of whether a
> PR has been merged or not, at the very least.
>

Yes, when we push it directly we have to make sure to do it carefully and
add PR# manually

>
> I'm expressing this concern because I do not see any option to "override"
> the enable or disable automerge feature and merge
> it myself.
>
>
Yes. There is none.


> Would love it if someone could help me with that information.
>
> P.S: It could be that I am not able to force merge because someone else
> (Jarek) enabled the force merge for my PR?
>

Temp timing issue


>
> Thanks & Regards,
> Amogh Desai
>

------------------------------------------------------------------

Lof of fighting with GH naming:

commit 4a074c1b17726df4939fb8b426f6cb90b53f0881
Author: Jarek Potiuk <ja...@potiuk.com>
Date:   Sat Apr 26 15:12:36 2025 +0200

    Another attempt to set the right context

commit af977853743a97d5785a9b7f9ce63e7fd91cd133
Author: Jarek Potiuk <ja...@potiuk.com>
Date:   Sat Apr 26 14:49:51 2025 +0200

    Another attempt to set the right context

commit 97c5d9cf33e4c2f0654c744872ca8de452daa5ca
Author: Jarek Potiuk <ja...@potiuk.com>
Date:   Sat Apr 26 14:40:45 2025 +0200

    Another attempt to set the right context

commit 14d60c7ce99f30d3477a01d56dbce15460b11f28
Author: Jarek Potiuk <ja...@potiuk.com>
Date:   Sat Apr 26 14:33:05 2025 +0200

    Maybe this one will work?

commit 156d0e8080c20b5cb61315ac6118cbce5abf75a9
Author: Jarek Potiuk <ja...@potiuk.com>
Date:   Sat Apr 26 14:21:51 2025 +0200

    Another attempt to set the right context

commit 1adf5afcc9cca4a6492359b2883b5348f60e7f9f
Author: Jarek Potiuk <ja...@potiuk.com>
Date:   Sat Apr 26 12:56:08 2025 +0200

    Proper (?) context for branch protection experiment (#49815)



> On Sat, Apr 26, 2025 at 5:41 PM Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > Hello everyone,
> >
> > With some initial teething problems we've enabled an "experimental"
> feature
> > of "auto-merging" PRs in our repo. It should potentially help with
> "focus"
> > of maintainers, because they will not have to come-back to the PRs to
> merge
> > it once they enabled auto-merge for them.
> >
> > It works in the way, that when "required status checks", "reviews" and
> > "resolved conversations" (the required conditions for "main" protected
> > branch) are not met, committer can use "Enable auto-merge" on the PR and
> > when all conditions are met, the PR will get merged automatically.
> >
> > But after enabling it, it turns out that this has one **serious**
> drawback.
> > We currently cannot override the protection from GitHub UI, and it's not
> > possible to merge PR that did not pass one of the checks (So "Finalize
> > tests / Summarize warnings" has to complete successfully in order to be
> > able to merge PR,
> >
> > This is quite a bit of a blocker. But not entirely, because I've learned
> (I
> > did not know it before) that we (committers) already have a way to bypass
> > ANY protection - by directly pushing code to main branch via gitbox URL
> > exposed by Apache Infrastructure:
> >
> > https://gitbox.apache.org/repos/asf
> >
> > Specifically - you can set this as remote
> > https://gitbox.apache.org/repos/asf/airflow.git - and push changes
> > directly
> > to "main" branch. It will bypass any protection. You do not even need to
> > get a review from another maintainer (yes - I just tested it and it
> works).
> > You just need to authenticate with your apache id / password.
> >
> > That is not great from a security and provenance point of view, but well,
> > ASF allows it for now (which is something we will have to fix eventually
> I
> > think.  It requires using git CLI/local client to push such branches and
> > there are some small things we have to remember (like manually adding PR
> #
> > to the branch we are pushing or not having PR# in the merged commit at
> > all).
> >
> > Certainly not as convenient as the merge button in PR - but workable if
> we
> > want to merge something quickly, regardless of the status (and apparently
> > regardless of review / approval which is a bummer).
> >
> > I  left it enabled for a moment - the weekend maximum and maybe beginning
> > of Monday and would love to hear what you think.
> >
> > J.
> >
>

Re: [DISCUSS} Enabled experiment auto-merge feature

[Amogh Desai <am...@gmail.com>]

I am not sure if I like this feature a lot with my recent experience with
this PR: https://github.com/apache/airflow/pull/49692.

On the PR status, it mentions "finalize tests" is waiting to report status
but when i describe the tests, I see that task has completed.

It is quite confusing to me with this experience at least. But, maybe I
need some getting used to.

Speaking from a general perspective and in time sensitive situations like
cutting an RC, I am sure
we would like to have some PRs in as and when they pass CI / sometimes
don't pass (known CI issues going on).

This will make it slightly inconvenient and hard to keep track of whether a
PR has been merged or not, at the very least.

I'm expressing this concern because I do not see any option to "override"
the enable or disable automerge feature and merge
it myself.

Would love it if someone could help me with that information.

P.S: It could be that I am not able to force merge because someone else
(Jarek) enabled the force merge for my PR?

Thanks & Regards,
Amogh Desai


On Sat, Apr 26, 2025 at 5:41 PM Jarek Potiuk <ja...@potiuk.com> wrote:

> Hello everyone,
>
> With some initial teething problems we've enabled an "experimental" feature
> of "auto-merging" PRs in our repo. It should potentially help with "focus"
> of maintainers, because they will not have to come-back to the PRs to merge
> it once they enabled auto-merge for them.
>
> It works in the way, that when "required status checks", "reviews" and
> "resolved conversations" (the required conditions for "main" protected
> branch) are not met, committer can use "Enable auto-merge" on the PR and
> when all conditions are met, the PR will get merged automatically.
>
> But after enabling it, it turns out that this has one **serious** drawback.
> We currently cannot override the protection from GitHub UI, and it's not
> possible to merge PR that did not pass one of the checks (So "Finalize
> tests / Summarize warnings" has to complete successfully in order to be
> able to merge PR,
>
> This is quite a bit of a blocker. But not entirely, because I've learned (I
> did not know it before) that we (committers) already have a way to bypass
> ANY protection - by directly pushing code to main branch via gitbox URL
> exposed by Apache Infrastructure:
>
> https://gitbox.apache.org/repos/asf
>
> Specifically - you can set this as remote
> https://gitbox.apache.org/repos/asf/airflow.git - and push changes
> directly
> to "main" branch. It will bypass any protection. You do not even need to
> get a review from another maintainer (yes - I just tested it and it works).
> You just need to authenticate with your apache id / password.
>
> That is not great from a security and provenance point of view, but well,
> ASF allows it for now (which is something we will have to fix eventually I
> think.  It requires using git CLI/local client to push such branches and
> there are some small things we have to remember (like manually adding PR #
> to the branch we are pushing or not having PR# in the merged commit at
> all).
>
> Certainly not as convenient as the merge button in PR - but workable if we
> want to merge something quickly, regardless of the status (and apparently
> regardless of review / approval which is a bummer).
>
> I  left it enabled for a moment - the weekend maximum and maybe beginning
> of Monday and would love to hear what you think.
>
> J.
>