Hi Dian, This is awesome, thanks for the quick action on merging the backport PRs! I'll proceed with the release process based on this, and update the docs as well.
Thanks, Ferenc On Thursday, May 29th, 2025 at 04:59, Dian Fu <dian0511...@gmail.com> wrote: > > > Hi Ferenc, > > This should have already been supported. See FLINK-34487 [1] for more > details. I have checked the GHA nightly of the master branch and it > works well. The problem is that the backport PRs for release branchs > were not merged (which is not intended). I will follow up with the > backport PRs. Could you > help to verify the release process using GHA and also help to update > the release doc if necessary? > > Regards, > Dian > > [1] https://issues.apache.org/jira/browse/FLINK-34487 > > > On Wed, May 28, 2025 at 10:00 PM Gabor Somogyi > gabor.g.somo...@gmail.com wrote: > > > Hi Ferenc, > > > > +1 from my side on directional perspective. > > Such job would be useful even for local python code testing (certain > > changes break wheel packaging and testing all platforms are horror). > > > > I've some questions/suggestions on the details though: > > * I see it build macos-13, macos-14 but can't see 15. Don't we build that > > and that's the reason why here missing or just forgotten? > > * manylinux2014 and manylinux1 has quite some difference. Since the latter > > is very old (CentOS 5 (2007)) and deprecated > > I would vote one migration but it would require quite some testing. > > * Do I understand correctly that all wheels are intended to be built such a > > way or just part of it? > > > > BR, > > G > > > > On Wed, May 28, 2025 at 3:27 PM Ferenc Csaky ferenc.cs...@pm.me.invalid > > wrote: > > > > > Hello devs, > > > > > > I am in the process of creating the 1.19.3 and 1.20.2 patch releases, and > > > arriving to the step of preparing the PyFlink wheel files, I was surprised > > > by > > > the fact that the suggested way is to use the Azure Pipeline [1], which > > > points > > > to a deprecated doc on how to deploy a pipeline, etc. Anyways, I do not > > > have > > > an Azure account, and to register one it requires to give a lot of > > > personal > > > info (name, address, credit card) to Microsoft, so IMO it is not feasible > > > to > > > expect any committer to setup an Azure account and use that to produce > > > wheel > > > builds. > > > > > > I checked what we exactly do under the hood here, and I see that for > > > MacOS, > > > we already utilizing `cibuildwheel`. So my question is, do we have > > > anything > > > against simply setting up a GitHub workflow that uses `cibuildwheel` for > > > both > > > OS? That workflow can be manually triggered by the release manager on > > > their > > > fork, so it still be isolated from the upstream repo. The only difference > > > I > > > found is that `cibuildwheel` cannot build for `manylinux1`, and uses > > > `manylinux2014` instead, but AFAIK that does not matter. > > > > > > I already set up a GH workflow [2] and also produced wheel files with it > > > [3]. > > > I would like to propose to transition to this model for building wheel > > > files, > > > cause it a lot simpler, and does not depend on anything other than GitHub. > > > > > > WDYT? > > > > > > Best, > > > Ferenc > > > > > > [1] > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=73631092#CreatingaFlinkRelease-BuildandstageJavaandPythonartifacts > > > [2] > > > https://github.com/ferenc-csaky/flink/commit/cea118f948e1eec435d6827a6eee0bafe6bb71d2 > > > [3] https://github.com/ferenc-csaky/flink/actions/runs/15281370107
