> Why was a workflow change that impacts every. single. PR. not discussed
in this list before turning it on? I can’t think of a more impactful change
to committers.
My mistake. It should be - similar as all the other things we discussed
then. I actually thought we discussed it. I will do better ne
> I also tend to be -1 on this.
So If there are also few others who have opinions here - (other than yes, I
really thought we discussed it in devlist before - but it seems it was only
on slack where we discussed it at length) - from what I see - clearly that
the "escape hatch" does not cut it and
And yes - apologies once again i have not checked and discussed it before.
We SHOULD discuss it in devlist - and I **should** hold myself accountable
to that similarly as I hold others, and I hope - similarly - when we see
other important things not being discussed here - people will not complain
a
Yep - all the dags will be visible in `breeze` in my PR
https://github.com/apache/airflow/pull/49978 - just pushed a change for it:
[image: image.png]
On Wed, Apr 30, 2025 at 4:31 PM Jarek Potiuk wrote:
> Answering Constance (somewhat it went to another thread:)
>
> > I know we rely on the exam
Hello here.
While fixing a bug in the doc generation to bring "source" link to example
dags https://github.com/apache/airflow/pull/49978 I realized that we have
not moved a number of python/bash etc. example dags to standard provider -
where they now belong. I do it as part of my PR - but as resul
Why was a workflow change that impacts every. single. PR. not discussed in this
list before turning it on? I can’t think of a more impactful change to
committers.
Just last month weren’t you saying we needed to have more discussion about
impactful change on this list?
> On 30 Apr 2025, at 1
just an idea: With "git bundles", maybe example DAGs from standard provider
can be dynamically imported?
But from your options: (1) seems reasonable
On Wed, 30 Apr 2025 at 15:07, Jarek Potiuk wrote:
> Hello here.
>
> While fixing a bug in the doc generation to bring "source" link to example
> d
Maybe I need to get used to the `escape hatch` (which I don't really like
tbh), but I've been having a really hard time not being able to merge
things with unrelated CI failure:
- Asking people to rebase again numerous time, until CI gets green, for
instance https://github.com/apache/airflow/pull/
Answering Constance (somewhat it went to another thread:)
> I know we rely on the example dags for dev purposes, especially for UI
development. As part of moving them out of core, can we update breeze to
automatically load them from their new home?
Yes. Very good point. I strongly think we need
Regarding what we need, though, I don't think we want to disable branch
protection or allow overriding it. If that happens, PRs can be merged to
main without any approval. What we really need if we enable auto-merge is
some way to bypass and manually merge the PR without waiting for all checks
to b
Hey all,
As a concept, it can save us and make the main stable for the things
slipping from eyes. I agree and experincing myself as well hard time asking
rebase on unrelated faluires. I haven't used the `escape hatch` myself. I
always tried to make it green. It is indeed a bit time consuming at st
Exactly!
> That is an interesting point - yes, there is no way to say "only bypass
> some branch protection features" - it's either all or none.
Correct, good reminder, but the question is what do we want? I don't think
we want that. So just because one flaw exists (which would hopefully be
fix
> Regarding what we need, though, I don't think we want to disable branch
protection or allow overriding it. If that happens, PRs can be merged to
main without any approval. What we really need if we enable auto-merge is
some way to bypass and manually merge the PR without waiting for all checks
to
I think I agree with option1, if the user chose to show example_dags then they
should get what they asked for. Option 2 feels like a cleaner option,
essentially curating the examples for new users, but it's opening a can of
worms debating which are "important" and where we draw the line, etc. S
The PR is finally green, sources updated, example dags moved to "standard
provider", yet in breeze they are visible. I run all the local testing in
Breeze for the moved dags and they work nicely.
I think we might continue discussing what should be the "final" approach -
but for now - merging that
A comment here - and we would not have learned all that without us trying
it first ! So - in retrospect - I am glad I did it, and we should do it
more often IMHO to try and see and then go back with learnings (but yes, it
should have been discussed at devlist if even briefly). That discussion
woul
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
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
enablin
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 lat
On Wed, Apr 30, 2025 at 7:55 AM Kaxil Naik 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 r
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 fo
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 wrote:
> Jarek & I discussed it on Slack in #internal-airflow-ci-cd. Summary b
I know we rely on the example dags for test purposes, especially for UI
development. As part of moving them out of core, can we update breeze to
automatically load them from their new home?
On Wed, Apr 30, 2025 at 7:12 AM Kaxil Naik wrote:
> just an idea: With "git bundles", maybe example DAGs f
s/test/dev
On Wed, Apr 30, 2025 at 8:49 AM Constance Martineau
wrote:
> I know we rely on the example dags for test purposes, especially for UI
> development. As part of moving them out of core, can we update breeze to
> automatically load them from their new home?
>
> On Wed, Apr 30, 2025 at 7:
Yeah, along Jens lines...
Yes, probably too many example dags. Probably this is a consequence of
using them as test dags.
Probably ideally we are more selective in curating example dags and
distinguishing them from test dags.
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
I'd be happy to help with the proposal as well Jens, you can count me in.
--
Regards,
Aritra Basu
On Thu, 1 May 2025, 2:43 am Jarek Potiuk, wrote:
> Very nice summary Jens and I 100% agree with the proposal.
>
> And BTW, this is not as difficult to implement as we might think. With
> bundle impl
Thanks for opening the discussion.
I have since a longer time the idea that we need to clean and re-work
the examples. I like how examples are used in some places in docs and
that examples. But at least 50% of them do not add real value to be
loaded. I think these are too many.
I'd propose t
I retract my previous answer and agree with Jens.Well said! That's a
bigger lift to get it done, so maybe not part of the immediate migration, but
it would be a nice overall improvement project.
- ferruzzi
From: Jens Scheffler
Sent: Wednesday, April 30,
Very nice summary Jens and I 100% agree with the proposal.
And BTW, this is not as difficult to implement as we might think. With
bundle implementation, making providers contribute their own
"example_bundle" seems like a very natural thing to do - this is actually
what I implemented in order to sh
30 matches
Mail list logo
