Re: [ANNOUNCE] New committer: Piotr Szuberski

[Tobiasz Kędzierski]

Congrats Piotrek!

On Fri, Jan 22, 2021 at 6:54 PM Brian Hulette  wrote:

> Congratulations Piotr, and thank you for all your contributions!
>
> On Fri, Jan 22, 2021 at 9:45 AM Robert Bradshaw 
> wrote:
>
>> Thanks, Piotr. Well deserved.
>>
>> On Fri, Jan 22, 2021 at 9:22 AM Tyson Hamilton 
>> wrote:
>>
>>> Congrats Piotr! Well deserved.
>>>
>>> On Fri, Jan 22, 2021 at 9:18 AM Ismaël Mejía  wrote:
>>>
 Congratulations Piotr ! Thanks for all your work !

 On Fri, Jan 22, 2021 at 5:33 PM Alexey Romanenko
  wrote:
 >
 > Hi everyone,
 >
 > Please join me and the rest of the Beam PMC in welcoming a new
 committer: Piotr Szuberski .
 >
 > Piotr started to contribute to Beam about one year ago and he did it
 very actively since then. He contributed to the different areas, like
 adding a cross-language functionality to existing IOs, improving ITs and
 performance tests environment/runtime, he actively worked on dependency
 updates [1].
 >
 > In consideration of his contributions, the Beam PMC trusts him with
 the responsibilities of a Beam committer [2].
 >
 > Thank you for your contributions, Piotr!
 >
 > -Alexey, on behalf of the Apache Beam PMC
 >
 > [1]
 https://github.com/apache/beam/pulls?q=is%3Apr+author%3Apiotr-szuberski
 > [2]
 https://beam.apache.org/contribute/become-a-committer/#an-apache-beam-committer
 >
 >

>>>

Re: Builds Meeting this Thursday

[Tobiasz Kędzierski]

Thanks Gavin for the detailed response.

> I'll ensure it gets looked into. If you could edit the meeting wiki page
with the above even better :)

Unfortunately I don't have permissions to edit cwiki.

BR
Tobiasz

On Thu, Jan 14, 2021 at 1:35 AM Pablo Estrada  wrote:

> Hi all,
> I've found out about this presentation on Apache Builds. Sharing with dev@
> in case it's of interest to anyone. See the agenda:
> https://cwiki.apache.org/confluence/display/INFRA/ASF+Builds+Agenda+2021-01-14
> Best
> -P.
>
> -- Forwarded message -
> From: Jarek Potiuk 
> Date: Tue, Jan 12, 2021 at 1:45 PM
> Subject: Fwd: Builds Meeting this Thursday
> To: 
>
>
> For those who are interested in performance/security of Github Actions,
> there is a meeting of "builds" for ASF this Thursday - where Brian Douglas
> Github's Staff Developers Advocate will be present.
>
> J.
>
> -- Forwarded message -
> From: Jarek Potiuk 
> Date: Tue, Jan 12, 2021 at 10:42 PM
> Subject: Re: Builds Meeting this Thursday
> To: , 
>
>
> Added my two topics. Thanks Gavin for this opportunity !
>
> On Tue, Jan 12, 2021 at 10:20 PM Gavin McDonald 
> wrote:
>
>> Please list on the cwiki meeting page any questions you have
>> for Brian so that I may send them to him ahead of time, if
>> possible.
>>
>> On Tue, Jan 12, 2021 at 10:00 PM Gavin McDonald 
>> wrote:
>>
>> > Hi All,
>> >
>> > Cwiki page -
>> > https://cwiki.apache.org/confluence/display
>> 
>
>
> On Tue, Jan 12, 2021 at 10:20 PM Gavin McDonald 
> wrote:
> Please list on the cwiki meeting page any questions you have
> for Brian so that I may send them to him ahead of time, if
> possible.
>
> On Tue, Jan 12, 2021 at 10:00 PM Gavin McDonald 
> wrote:
>
> > Hi All,
> >
> > Cwiki page -
> >
> https://cwiki.apache.org/confluence/display/INFRA/ASF+Builds+Agenda+2021-01-14
> >
> >
> >
> > On Tue, Jan 12, 2021 at 9:53 PM Gavin McDonald 
> > wrote:
>
>> >/INFRA/ASF+Builds+Agenda+2021-01-14
>> 
>> >
>> >
>> >
>> > On Tue, Jan 12, 2021 at 9:53 PM Gavin McDonald 
>> > wrote:
>> >
>> >> Hi All,
>> >>
>> >> Sorry for the last minute notice, this Thursday the 14th January
>> >> at 1700 UTC time will be our next builds@ meeting.
>> >>
>> >> Just confirmed a few minutes ago, there will be a guest
>> >> representing Github on the call to talk about and answer
>> >> questions around Github Actions.
>> >>
>> >> The remainder of the call are self set topics , so whatever
>> >> else you guys want to cover.
>> >>
>> >> We will try Jitsi again, will a fallback url provided.
>> >> More details to follow
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> *Gavin McDonald*
>> >> Systems Administrator
>> >> ASF Infrastructure Team
>> >>
>> >
>> >
>> > --
>> >
>> > *Gavin McDonald*
>> > Systems Administrator
>> > ASF Infrastructure Team
>> >
>>
>>
>> --
>>
>> *Gavin McDonald*
>> Systems Administrator
>> ASF Infrastructure Team
>>
>
>
> --
> +48 660 796 129 <+48%20660%20796%20129>
>
>
> --
> +48 660 796 129 <+48%20660%20796%20129>
>

Re: Running direct runner test on windows

[Tobiasz Kędzierski]

Hi Haizhou,

I suppose these quotations mark are handled here:
https://github.com/apache/beam/blob/8cdb8075b7d28e84591b13fb01d0144d941a5ef2/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L1518

I was struggling with them while doing GA workflows which runs on
linux/mac/windows:
https://github.com/apache/beam/blob/master/.github/workflows/java_tests.yml

BR
Tobiasz

On Sun, Nov 29, 2020 at 8:45 AM Haizhou Zhao 
wrote:

> Hello Folks,
>
> I'm Haizhou, and I'm new to Beam code base. When I was running
> 'needsRunnerTests' with  'DirectRunner' on Windows 10, I found that the
> pipeline option[1] could not be parsed on Windows 10 but was running
> perfectly on my ubuntu desktop.
>
> It seems after groovy setting system property and java getting system
> property at the time of pipeline construction, Windows will drop the quotes
> so that the string
>
> ["--runner=DirectRunner", "--runnerDeterminedSharding=false"]
>
> becomes
>
> [--runner=DirectRunner, --runnerDeterminedSharding=false]
>
> which will fail the object mapper parsing. What solved the issue for me on
> Windows 10 was adding single quotes around, like
>
> ['"--runner=DirectRunner"', '"--runnerDeterminedSharding=false"']
>
> But, the above modification does not work on ubuntu/linux. Not an expert
> on OS encoding, I was wondering if anyone has run into the same issue
> before, and is there a good way to support this test on both Operating
> Systems.
>
> Thank you,
> Haizhou Zhao
>
> [1]
> https://github.com/apache/beam/blob/master/runners/direct-java/build.gradle#L104
>
>
>

Re: Shutting down Perfkit Explorer

[Tobiasz Kędzierski]

I agree with Robert, putting some information instead of "hello world"
could prevent disabling GAE and connected problems in the future.
If a relevant Jira issue exists it would be a great idea to put a link to
it.
What do you think about adding a link to GCP documentation mentioning this
dependency [1] ?

BR Tobiasz

[1]
https://cloud.google.com/datastore/docs/reference/libraries#dependency_on_application



On Wed, Sep 23, 2020 at 5:33 PM Robert Burke  wrote:

> Perhaps instead of "hello world" the message could refer to a jira about
> the Datastore IT tests?
> I suspect if we don't we'll just have a repeat of "we shut down app engine
> since it was just running a hello world, and the Datastore tests died".
>
> On Wed, Sep 23, 2020, 8:14 AM Kamil Wasilewski <
> kamil.wasilew...@polidea.com> wrote:
>
>> An error message that Udi sent is pretty self explanatory. Disabling
>> Google App Engine caused Datastore to be not accessible too. What's
>> interesting, it doesn't make any difference if the application on GAE is
>> actually using Datastore or not. GAE must be simply turned on and that's
>> the only requirement.
>>
>> I replaced Perfkit Explorer with a simple "hello world" running on Python
>> 3.8. I ran Datastore IT tests and they passed, so I think this solves the
>> problem. If something goes wrong, let me know!
>> Sorry for inconvenience and thanks Tyson for the rescue.
>>
>> On Tue, Sep 22, 2020 at 11:25 PM Udi Meiri  wrote:
>>
>>> Thanks, Tyson!
>>>
>>> On Tue, Sep 22, 2020 at 11:11 AM Tyson Hamilton 
>>> wrote:
>>>
 I re-enabled the AppEngine app. Today that app has both the required
 datastore app and the perfkit app baked into the container image. What
 should happen, is that the perfkit app is removed from that image, but the
 datastore related stuff remains functional.

 On Tue, Sep 22, 2020 at 10:37 AM Udi Meiri  wrote:

> Is it possible to create a simple "hello world" application instead?
>
> On Tue, Sep 22, 2020 at 10:35 AM Udi Meiri  wrote:
>
>> Disabling this broke our Datastore ITs. Apparently you must have an
>> application for Datastore to work. From the Datastore dashboard:
>> The project apache-beam-testing does not exist or it does not contain
>> an active Cloud Datastore or Cloud Firestore database. Please visit
>> http://console.cloud.google.com to create a project or
>> https://console.cloud.google.com/datastore/setup?project=apache-beam-testing
>> to add a Cloud Datastore or Cloud Firestore database. Note that Cloud
>> Datastore or Cloud Firestore always have an associated App Engine app and
>> this app must not be disabled.
>> New failure:
>> https://ci-beam.apache.org/job/beam_PostCommit_Python36/2959/
>>
>>
>>
>> On Tue, Sep 22, 2020 at 2:16 AM Kamil Wasilewski <
>> kamil.wasilew...@polidea.com> wrote:
>>
>>> Thanks. The application has been disabled.
>>>
>>> On Fri, Sep 18, 2020 at 8:46 PM Ahmet Altay 
>>> wrote:
>>>
 +1. Thank you for the cleanup.

 On Fri, Sep 18, 2020 at 8:24 AM Tyson Hamilton 
 wrote:

> +1 to removing, thank you Kamil.
>
> On Fri, Sep 18, 2020 at 6:05 AM Kamil Wasilewski <
> kamil.wasilew...@polidea.com> wrote:
>
>> Hello everyone,
>>
>> Beam support for Python 2 is coming to an end. Consequently, we
>> should make sure no Python 2 applications are running as a part of 
>> Beam's
>> infrastructure. As you may know, Beam is still hosting a Python 2
>> application on Google App Engine. This application is Perfkit 
>> Explorer [1].
>>
>> Perfkit Explorer has been used as a dashboarding tool for a long
>> time. Few months ago, it was deprecated in favour of new Grafana 
>> dashboards
>> [2].
>>
>> Perfkit Explorer doesn't support Python 3, so a viable solution
>> to the problem is to shut down Perfkit Explorer completely. That 
>> would also
>> reduce costs, because at the moment we have two similar applications 
>> doing
>> the same thing.
>>
>> What do you think?
>> If nobody has any objections, I'd like to shut down Perfkit
>> Explorer next week.
>>
>> Thanks,
>> Kamil
>>
>> [1] https://apache-beam-testing.appspot.com
>> [2] http://metrics.beam.apache.org/
>>
>

cwiki edit permission request

[Tobiasz Kędzierski]

Hi,

may I ask for edit permissions for the Beam cwiki page?
I would like to add information about metrics

BR
Tobiasz

Re: Beam Dependency Check Report (2020-08-03)

[Tobiasz Kędzierski]

I created PR [1] with the fix. PTAL

[1] https://github.com/apache/beam/pull/12716

On Fri, Aug 28, 2020 at 10:20 AM Tobiasz Kędzierski <
tobiasz.kedzier...@polidea.com> wrote:

> HI,
>
> I created JIRA [1] for this issue.
> I will try to fix it.
>
> [1] https://issues.apache.org/jira/browse/BEAM-10831
>
> On Mon, Aug 3, 2020 at 7:18 PM Damian Gadomski <
> damian.gadom...@polidea.com> wrote:
>
>> That's probably caused by this [1] PR, workspace had been deleted before
>> the email was sent.
>>
>> +Udi Meiri  Moving the workspace clean up to the very
>> end of post-build actions should help.
>>
>> [1] https://github.com/apache/beam/pull/12326
>>
>> On Mon, Aug 3, 2020 at 5:42 PM Brian Hulette  wrote:
>>
>>> Does anyone know what went wrong here? It looks like the
>>> associated jenkins job [1] succeeded, and produced
>>> beam-dependency-check-report.html
>>>
>>> [1] https://ci-beam.apache.org/job/beam_Dependency_Check/279/
>>>
>>> On Mon, Aug 3, 2020 at 5:28 AM Apache Jenkins Server <
>>> jenk...@builds.apache.org> wrote:
>>>
>>>> ERROR: File
>>>> 'src/build/dependencyUpdates/beam-dependency-check-report.html' does not
>>>> exist
>>>
>>>

-- 

Tobiasz Kędzierski
Polidea <https://www.polidea.com/> | Junior Software Engineer

E: tobiasz.kedzier...@polidea.com
[image: Polidea] <https://www.polidea.com/>

Check out our projects! <https://www.polidea.com/our-work>
[image: Github] <https://github.com/Polidea> [image: Facebook]
<https://www.facebook.com/Polidea.Software> [image: Twitter]
<https://twitter.com/polidea> [image: Linkedin]
<https://www.linkedin.com/company/polidea> [image: Instagram]
<https://instagram.com/polidea> [image: Behance]
<https://www.behance.net/polidea> [image: dribbble]
<https://dribbble.com/polideadesign>

Re: Beam Dependency Check Report (2020-08-03)

[Tobiasz Kędzierski]

HI,

I created JIRA [1] for this issue.
I will try to fix it.

[1] https://issues.apache.org/jira/browse/BEAM-10831

On Mon, Aug 3, 2020 at 7:18 PM Damian Gadomski 
wrote:

> That's probably caused by this [1] PR, workspace had been deleted before
> the email was sent.
>
> +Udi Meiri  Moving the workspace clean up to the very
> end of post-build actions should help.
>
> [1] https://github.com/apache/beam/pull/12326
>
> On Mon, Aug 3, 2020 at 5:42 PM Brian Hulette  wrote:
>
>> Does anyone know what went wrong here? It looks like the
>> associated jenkins job [1] succeeded, and produced
>> beam-dependency-check-report.html
>>
>> [1] https://ci-beam.apache.org/job/beam_Dependency_Check/279/
>>
>> On Mon, Aug 3, 2020 at 5:28 AM Apache Jenkins Server <
>> jenk...@builds.apache.org> wrote:
>>
>>> ERROR: File
>>> 'src/build/dependencyUpdates/beam-dependency-check-report.html' does not
>>> exist
>>
>>

Re: Email about build runs on my fork.

[Tobiasz Kędzierski]

Hi Alex,

After rebase on the latest master scheduled workflow should not run,
condition for scheduled job was extended to prevent situations like this.
As mentioned by Robert, you can disable gh action in case you don't need it.

BR
Tobiasz

On Thu, Jul 30, 2020 at 9:18 PM Robert Burke  wrote:

> You can disable GitHub actions on your own repos via the UI or via a code
> change
>
> https://github.community/t/how-can-i-disable-a-github-action/17049
>
> On Thu, Jul 30, 2020, 12:15 PM Ahmet Altay  wrote:
>
>> /cc +tobiasz.kedzier...@polidea.com  +Emily
>> Ye  -- this question is related to one of the recent
>> github action prs.
>>
>> On Thu, Jul 30, 2020 at 10:23 AM Alex Amato  wrote:
>>
>>> Hi,
>>>
>>> I received this email indicating some build was running on my fork,
>>> though I had not been doing any work on that fork for the last few weeks.
>>>
>>> I don't really need to run these builds on my fork and don't think we
>>> need to waste resources on this. Is there some way to prevent forks from
>>> doing this?
>>>
>>> I just rebased my own fork from apache beam master now. I am not sure if
>>> that will stop it or not, but it should now be up to date.
>>>
>>> -- Forwarded message -
>>> From: Alex Amato 
>>> Date: Wed, Jul 29, 2020 at 7:47 PM
>>> Subject: [ajamato/beam] Run failed: Build python wheels - master
>>> (9ca80ae)
>>> To: ajamato/beam 
>>> Cc: Ci activity 
>>>
>>>
>>> Run failed for master (9ca80ae)
>>>
>>> Repository: ajamato/beam
>>> Workflow: Build python wheels
>>> Duration: 29 minutes and 27.0 seconds
>>> Finished: 2020-07-30 02:47:17 UTC
>>>
>>> View results 
>>> Jobs:
>>>
>>>- build_source 
>>>succeeded (0 annotations)
>>>- Build wheels on ubuntu-latest
>>> succeeded (0
>>>annotations)
>>>- Build wheels on macos-latest
>>> succeeded (0
>>>annotations)
>>>- Prepare GCS 
>>>succeeded (0 annotations)
>>>- Upload source to GCS bucket
>>> failed (1
>>>annotation)
>>>- Tag repo nightly 
>>>succeeded (0 annotations)
>>>- Upload wheels to GCS bucket (ubuntu-latest)
>>> cancelled (2
>>>annotations)
>>>- Upload wheels to GCS bucket (macos-latest)
>>> failed (1
>>>annotation)
>>>- List files on Google Cloud Storage Bucket
>>> skipped (0
>>>annotations)
>>>
>>> —
>>> You are receiving this because this workflow ran on your branch.
>>> Manage your GitHub Actions notifications here
>>> .
>>>
>>

Re: Canceling Jenkins builds when the update to PR makes prior build irrelevant

[Tobiasz Kędzierski]

I think the experiment went quite well.
Now all nodes have the increased number of the executors [1]..
Canceling Jenkins builds after PR updates seems to work as well. Queue is
usually very short.

[1]: https://ci-beam.apache.org/label/beam/load-statistics?type=hour

BR
Tobiasz

On Mon, Jul 6, 2020 at 4:52 PM Tyson Hamilton  wrote:

> How did the experiment go? The load status graphs on the executors seem to
> show no increase in queued jobs [1]. There is a periodic bump every 6h,
> possibly due to cron firing off a bunch at the same time, that can also be
> seen by changing the timepsan in [1]. The number of executors on 1/4 of the
> nodes was also increased so the combination of these things make contention
> to appear quite low or even non-existent.
>
> [1]: https://ci-beam.apache.org/label/beam/load-statistics?type=hour
>
> On Mon, Jun 29, 2020 at 9:17 AM Tobiasz Kędzierski <
> tobiasz.kedzier...@polidea.com> wrote:
>
>> Hi
>>
>> Agree with Ahmet, that even in that shape it should improve the queue
>> length. Both _Commit/_Phrase cross-cancelling and "cancell all" phrase seem
>> require much effort and I doubt it's worthy to do it.
>>
>> I will turn on `Cancel build on update` in ghprb-plugin on
>> ci-beam.apache.org tomorrow (Tuesday).
>>
>> Some discussions related to job filtering issue (or feature) in
>> ghprb-plugin:
>> https://github.com/jenkinsci/ghprb-plugin/issues/678
>> https://github.com/jenkinsci/ghprb-plugin/pull/680
>>
>> BR
>> Tobiasz
>>
>> On Fri, Jun 26, 2020 at 2:07 AM Ahmet Altay  wrote:
>>
>>>
>>>
>>> On Thu, Jun 25, 2020 at 4:27 PM Tobiasz Kędzierski <
>>> tobiasz.kedzier...@polidea.com> wrote:
>>>
>>>> Andrew thanks for great analysis +1
>>>> This bug with job filtering seems to be crucial to keep _Commit and
>>>> _Phrase separate.
>>>>
>>>> I was considering the situation where the two PRs with the same commit
>>>> hash are created. I created an artificial situation where two branches are
>>>> identical and then two PRs with them. Two separate jobs were triggered. As
>>>> you wrote, due to the matching GH status by job name and hash, both PR
>>>> statuses were pointing to the same job (the newest one, which was wrong for
>>>> one PR). As i tested, adding a new commit which will cancel the previous
>>>> build would show false status on the PR with the previously wrong job link.
>>>> It is possible to reproduce it, but could you give the real life
>>>> situation where two jobs would be triggered with the same commit?
>>>> I am asking because I think that enabling `Cancel build on update` may
>>>> greatly improve Jenkins queue and it would be worthwhile to sacrifice this
>>>> rare and unlikely case for it (if it is rare and unlikely case of course).
>>>>
>>>
>>> I agree with this.
>>>
>>>
>>>>
>>>> Ahmet, I think the cancelling _Commit build by following _Phrase should
>>>> be handled within ghprb-plugin if possible. I am not sure if we can make
>>>> some workaround. Do you have any suggestions how we may solve it?
>>>>
>>>
>>> I do not know jenkins enough to be able to make a good suggestion. We
>>> can try:
>>> - If it is possible to do this with ghprb plugin as you suggested, we
>>> can do that.
>>> - If not, we can make _Commit jobs cancel _Commit jobs only and _Phrase
>>> jobs cancel _Phrase jobs only. It will still be an improvement.
>>>
>>>
>>>>
>>>> BR
>>>> Tobiasz
>>>>
>>>> On Wed, Jun 24, 2020 at 12:28 AM Kenneth Knowles 
>>>> wrote:
>>>>
>>>>> +1 to Andrew's analysis
>>>>>
>>>>> On Tue, Jun 23, 2020 at 12:13 PM Ahmet Altay  wrote:
>>>>>
>>>>>> Would it be possible to cancel any running _Phrase or _Commit
>>>>>> variants, if either one of them is triggered?
>>>>>>
>>>>>> On Tue, Jun 23, 2020 at 10:41 AM Andrew Pilloud 
>>>>>> wrote:
>>>>>>
>>>>>>> I believe we split _Commit and _Phrase to work around a bug with job
>>>>>>> filtering. For example, when you make a python change only the python 
>>>>>>> tests
>>>>>>> are run based on the commit. We still want to be able to run the java 
>>>>>>> jobs
>>>>>

Re: [PROPOSAL] Preparing for Beam 2.23.0 release

[Tobiasz Kędzierski]

Hi,

I've just created PR introducing usage of GH-Actions to release process
https://github.com/apache/beam/pull/12150

Let me know what you think, maybe you have some suggestions on what may be
improved.

BR
Tobiasz

On Wed, Jul 1, 2020 at 6:08 AM Ahmet Altay  wrote:

> Valentyn,
>
> +tobiasz.kedzier...@polidea.com  added a
> github action for building python wheel files (
> https://github.com/apache/beam/pull/11877). You should be able to build
> the wheel files using this github action instead of using the beam-wheels
> repo and Travis. Please give it a try during the release process.
>
> Ahmet
>
> On Tue, Jun 23, 2020 at 7:27 PM Valentyn Tymofieiev 
> wrote:
>
>> Friendly reminder that the release cut is slated next week.
>>
>> If you are aware of *release-blocking* issues, please open a JIRA and set
>> the "Fix version" to be 2.23.0.
>>
>> Please do not set "Fix version" for open non-blocking issues, instead set
>> "Fix version" once the issue is actually resolved.
>>
>> Thanks,
>> Valentyn
>>
>> On Mon, Jun 15, 2020 at 1:14 PM Rui Wang  wrote:
>>
>>> Thank you Valentyn!
>>>
>>> On Mon, Jun 15, 2020 at 1:08 PM Ahmet Altay  wrote:
>>>
>>>> Thank you Valentyn!
>>>>
>>>> On Mon, Jun 15, 2020 at 12:46 PM Ankur Goenka 
>>>> wrote:
>>>>
>>>>> Thanks Valentyn!
>>>>>
>>>>> On Mon, Jun 15, 2020 at 12:41 PM Kyle Weaver 
>>>>> wrote:
>>>>>
>>>>>> Sounds good, thanks Valentyn!
>>>>>>
>>>>>> On Mon, Jun 15, 2020 at 12:31 PM Valentyn Tymofieiev <
>>>>>> valen...@google.com> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> According to the Beam release calendar [1], the next (2.23.0)
>>>>>>> release branch cut is scheduled for July 1.
>>>>>>>
>>>>>>> I would be happy to help with this release and volunteer myself to
>>>>>>> be the next release manager.
>>>>>>>
>>>>>>> As usual, the plan is to cut the branch on that date, and cherrypick
>>>>>>> release-blocking fixes afterwards if any.
>>>>>>>
>>>>>>> Any unresolved release blocking JIRA issues for 2.23.0 should have
>>>>>>> their "Fix Version/s" marked as "2.23.0".
>>>>>>>
>>>>>>> Any comments or objections?
>>>>>>>
>>>>>>> [1]
>>>>>>> https://calendar.google.com/calendar/embed?src=0p73sl034k80oob7seouanigd0%40group.calendar.google.com
>>>>>>>
>>>>>>>

-- 

Tobiasz Kędzierski
Polidea <https://www.polidea.com/> | Junior Software Engineer

E: tobiasz.kedzier...@polidea.com
[image: Polidea] <https://www.polidea.com/>

Check out our projects! <https://www.polidea.com/our-work>
[image: Github] <https://github.com/Polidea> [image: Facebook]
<https://www.facebook.com/Polidea.Software> [image: Twitter]
<https://twitter.com/polidea> [image: Linkedin]
<https://www.linkedin.com/company/polidea> [image: Instagram]
<https://instagram.com/polidea> [image: Behance]
<https://www.behance.net/polidea> [image: dribbble]
<https://dribbble.com/polideadesign>

Re: [ANNOUNCE] New committer: Aizhamal Nurmamat kyzy

[Tobiasz Kędzierski]

Congratulations Aizhamal! :)

On Mon, Jun 29, 2020 at 11:50 PM Austin Bennett 
wrote:

> Congratulations, @Aizhamal Nurmamat kyzy  !
>
> On Mon, Jun 29, 2020 at 2:32 PM Valentyn Tymofieiev 
> wrote:
>
>> Congratulations and big thank you for all the hard work on Beam, Aizhamal!
>>
>> On Mon, Jun 29, 2020 at 9:56 AM Kenneth Knowles  wrote:
>>
>>> Please join me and the rest of the Beam PMC in welcoming a new
>>> committer: Aizhamal Nurmamat kyzy
>>>
>>> Over the last 15 months or so, Aizhamal has driven many efforts in the
>>> Beam community and contributed to others. Aizhamal started by helping with
>>> the Beam newsletter [1] then continued by contributing to meetup planning
>>> [2] [3] and Beam Summit planning [4]. Aizhamal created Beam's system for
>>> managing social media [5] and contributed many tweets, coordinated the vote
>>> and design of Beam's mascot [6] [7], drove migration of Beam's site to a
>>> more i18n-friendly infrastructure [8], kept on top of Beam's enrollment in
>>> Season of Docs [9], and even organized remote Beam Webinars during the
>>> pandemic [10].
>>>
>>> In consideration of Aizhamal's contributions, the Beam PMC trusts her
>>> with
>>> the responsibilities of a Beam committer [11].
>>>
>>> Thank you, Aizhamal, for your contributions and looking forward to many
>>> more!
>>>
>>> Kenn, on behalf of the Apache Beam PMC
>>>
>>> [1]
>>> https://lists.apache.org/thread.html/447ae9fdf580ad88522aabc8a0f3703c51acd8885578bb422389a4b0%40%3Cdev.beam.apache.org%3E
>>> [2]
>>>
>>> https://lists.apache.org/thread.html/ebeeae53a64dca8bb491e26b8254d247226e6d770e33dbc9428202df%40%3Cdev.beam.apache.org%3E
>>> [3]
>>>
>>> https://lists.apache.org/thread.html/rc31d3d57b39e6cf12ea3b6da0e884f198f8cbef9a73f6a50199e0e13%40%3Cdev.beam.apache.org%3E
>>> [4]
>>>
>>> https://lists.apache.org/thread.html/99815d5cd047e302b0ef4b918f2f6db091b8edcf430fb62e4eeb1060%40%3Cdev.beam.apache.org%3E
>>> [5]
>>> https://lists.apache.org/thread.html/babceeb52624fd4dd129c259db8ee9017cb68cba069b68fca7480c41%40%3Cdev.beam.apache.org%3E
>>> [6]
>>>
>>> https://lists.apache.org/thread.html/60aa4b149136e6aa4643749731f4b5a041ae4952e7b7e57654888bed%40%3Cdev.beam.apache.org%3E
>>> [7]
>>>
>>> https://lists.apache.org/thread.html/r872ba2860319cbb5ca20de953c43ed7d750155ca805cfce3b70085b0%40%3Cdev.beam.apache.org%3E
>>> [8]
>>>
>>> https://lists.apache.org/thread.html/rfab4cc1411318c3f4667bee051df68f37be11846ada877f3576c41a9%40%3Cdev.beam.apache.org%3E
>>> [9]
>>>
>>> https://lists.apache.org/thread.html/r4df2e596751e263a83300818776fbb57cb1e84171c474a9fd016ec10%40%3Cdev.beam.apache.org%3E
>>> [10]
>>>
>>> https://lists.apache.org/thread.html/r81b93d700fedf3012b9f02f56b5d693ac4c1aac1568edf9e0767b15f%40%3Cuser.beam.apache.org%3E
>>> [11]
>>>
>>> https://beam.apache.org/contribute/become-a-committer/#an-apache-beam-committer
>>>
>>

Re: Canceling Jenkins builds when the update to PR makes prior build irrelevant

[Tobiasz Kędzierski]

Hi

Agree with Ahmet, that even in that shape it should improve the queue
length. Both _Commit/_Phrase cross-cancelling and "cancell all" phrase seem
require much effort and I doubt it's worthy to do it.

I will turn on `Cancel build on update` in ghprb-plugin on
ci-beam.apache.org tomorrow (Tuesday).

Some discussions related to job filtering issue (or feature) in
ghprb-plugin:
https://github.com/jenkinsci/ghprb-plugin/issues/678
https://github.com/jenkinsci/ghprb-plugin/pull/680

BR
Tobiasz

On Fri, Jun 26, 2020 at 2:07 AM Ahmet Altay  wrote:

>
>
> On Thu, Jun 25, 2020 at 4:27 PM Tobiasz Kędzierski <
> tobiasz.kedzier...@polidea.com> wrote:
>
>> Andrew thanks for great analysis +1
>> This bug with job filtering seems to be crucial to keep _Commit and
>> _Phrase separate.
>>
>> I was considering the situation where the two PRs with the same commit
>> hash are created. I created an artificial situation where two branches are
>> identical and then two PRs with them. Two separate jobs were triggered. As
>> you wrote, due to the matching GH status by job name and hash, both PR
>> statuses were pointing to the same job (the newest one, which was wrong for
>> one PR). As i tested, adding a new commit which will cancel the previous
>> build would show false status on the PR with the previously wrong job link.
>> It is possible to reproduce it, but could you give the real life
>> situation where two jobs would be triggered with the same commit?
>> I am asking because I think that enabling `Cancel build on update` may
>> greatly improve Jenkins queue and it would be worthwhile to sacrifice this
>> rare and unlikely case for it (if it is rare and unlikely case of course).
>>
>
> I agree with this.
>
>
>>
>> Ahmet, I think the cancelling _Commit build by following _Phrase should
>> be handled within ghprb-plugin if possible. I am not sure if we can make
>> some workaround. Do you have any suggestions how we may solve it?
>>
>
> I do not know jenkins enough to be able to make a good suggestion. We can
> try:
> - If it is possible to do this with ghprb plugin as you suggested, we can
> do that.
> - If not, we can make _Commit jobs cancel _Commit jobs only and _Phrase
> jobs cancel _Phrase jobs only. It will still be an improvement.
>
>
>>
>> BR
>> Tobiasz
>>
>> On Wed, Jun 24, 2020 at 12:28 AM Kenneth Knowles  wrote:
>>
>>> +1 to Andrew's analysis
>>>
>>> On Tue, Jun 23, 2020 at 12:13 PM Ahmet Altay  wrote:
>>>
>>>> Would it be possible to cancel any running _Phrase or _Commit variants,
>>>> if either one of them is triggered?
>>>>
>>>> On Tue, Jun 23, 2020 at 10:41 AM Andrew Pilloud 
>>>> wrote:
>>>>
>>>>> I believe we split _Commit and _Phrase to work around a bug with job
>>>>> filtering. For example, when you make a python change only the python 
>>>>> tests
>>>>> are run based on the commit. We still want to be able to run the java jobs
>>>>> by trigger phrase if needed. There are also performance tests (Nexmark for
>>>>> example) that have different jobs to ensure PR runs don't end up published
>>>>> in the performance dashboard, but i think those have a split of _Phrase 
>>>>> and
>>>>> _Cron.
>>>>>
>>>>> As for canceling jobs, don't forget that the github status APIs are
>>>>> keyed on commit hash and job name (not PR). It is possible for a commit to
>>>>> be on multiple PRs and it is possible for a single PR to have
>>>>> multiple commits. There are workflows that will be broken if you are 
>>>>> keying
>>>>> off of a PR to automatically cancel jobs.
>>>>>
>>>>> On Tue, Jun 23, 2020 at 9:59 AM Tyson Hamilton 
>>>>> wrote:
>>>>>
>>>>>> +1 the ability to cancel in-flight jobs is worth deduplicating
>>>>>> _Phrase and _Commit. I don't see a benefit for having both.
>>>>>>
>>>>>> On Tue, Jun 23, 2020 at 9:02 AM Luke Cwik  wrote:
>>>>>>
>>>>>>> I think this is a great improvement to prevent the Jenkins queue
>>>>>>> from growing too large and has been suggested in the past but we were
>>>>>>> unable to do due to difficulty with the version of the ghrpb plugin that
>>>>>>> was used at the time.
>>>>>>>
>>>>>>> I know that we created different 

Re: Canceling Jenkins builds when the update to PR makes prior build irrelevant

[Tobiasz Kędzierski]

Andrew thanks for great analysis +1
This bug with job filtering seems to be crucial to keep _Commit and _Phrase
separate.

I was considering the situation where the two PRs with the same commit hash
are created. I created an artificial situation where two branches are
identical and then two PRs with them. Two separate jobs were triggered. As
you wrote, due to the matching GH status by job name and hash, both PR
statuses were pointing to the same job (the newest one, which was wrong for
one PR). As i tested, adding a new commit which will cancel the previous
build would show false status on the PR with the previously wrong job link.
It is possible to reproduce it, but could you give the real life situation
where two jobs would be triggered with the same commit?
I am asking because I think that enabling `Cancel build on update` may
greatly improve Jenkins queue and it would be worthwhile to sacrifice this
rare and unlikely case for it (if it is rare and unlikely case of course).

Ahmet, I think the cancelling _Commit build by following _Phrase should be
handled within ghprb-plugin if possible. I am not sure if we can make some
workaround. Do you have any suggestions how we may solve it?

BR
Tobiasz

On Wed, Jun 24, 2020 at 12:28 AM Kenneth Knowles  wrote:

> +1 to Andrew's analysis
>
> On Tue, Jun 23, 2020 at 12:13 PM Ahmet Altay  wrote:
>
>> Would it be possible to cancel any running _Phrase or _Commit variants,
>> if either one of them is triggered?
>>
>> On Tue, Jun 23, 2020 at 10:41 AM Andrew Pilloud 
>> wrote:
>>
>>> I believe we split _Commit and _Phrase to work around a bug with job
>>> filtering. For example, when you make a python change only the python tests
>>> are run based on the commit. We still want to be able to run the java jobs
>>> by trigger phrase if needed. There are also performance tests (Nexmark for
>>> example) that have different jobs to ensure PR runs don't end up published
>>> in the performance dashboard, but i think those have a split of _Phrase and
>>> _Cron.
>>>
>>> As for canceling jobs, don't forget that the github status APIs are
>>> keyed on commit hash and job name (not PR). It is possible for a commit to
>>> be on multiple PRs and it is possible for a single PR to have
>>> multiple commits. There are workflows that will be broken if you are keying
>>> off of a PR to automatically cancel jobs.
>>>
>>> On Tue, Jun 23, 2020 at 9:59 AM Tyson Hamilton 
>>> wrote:
>>>
>>>> +1 the ability to cancel in-flight jobs is worth deduplicating _Phrase
>>>> and _Commit. I don't see a benefit for having both.
>>>>
>>>> On Tue, Jun 23, 2020 at 9:02 AM Luke Cwik  wrote:
>>>>
>>>>> I think this is a great improvement to prevent the Jenkins queue from
>>>>> growing too large and has been suggested in the past but we were unable to
>>>>> do due to difficulty with the version of the ghrpb plugin that was used at
>>>>> the time.
>>>>>
>>>>> I know that we created different variants of the tests because we
>>>>> wanted to track metrics based upon whether something was a post commit
>>>>> (_Cron suffix) vs precommits but don't know why we split _Phrase and
>>>>> _Commit.
>>>>>
>>>>> On Tue, Jun 23, 2020 at 3:35 AM Tobiasz Kędzierski <
>>>>> tobiasz.kedzier...@polidea.com> wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> I was investigating the possibility of canceling Jenkins builds when
>>>>>> the update to PR makes prior build irrelevant. (related to
>>>>>> https://issues.apache.org/jira/browse/BEAM-3105)
>>>>>> In the `GitHub Pull Request Builder Jenkins plugin [ghprb-plugin]
>>>>>> there is a hidden option `Cancel build on update` that seems to work 
>>>>>> fine.
>>>>>> e.g.
>>>>>>
>>>>>>1.
>>>>>>
>>>>>>I make a PR
>>>>>>2.
>>>>>>
>>>>>>ghprb-plugin triggers  beam_PreCommit_PythonLint_Commit
>>>>>>3.
>>>>>>
>>>>>>I make a new commit to the PR
>>>>>>
>>>>>>4.
>>>>>>
>>>>>>ghprb-plugin aborts the previous
>>>>>>`beam_PreCommit_PythonLint_Commit` and adds to the queue the new one 
>>>>>> with
>>>>>>updated sha1.
>>>>>>
>&

Canceling Jenkins builds when the update to PR makes prior build irrelevant

[Tobiasz Kędzierski]

Hi everyone,

I was investigating the possibility of canceling Jenkins builds when the
update to PR makes prior build irrelevant. (related to
https://issues.apache.org/jira/browse/BEAM-3105)
In the `GitHub Pull Request Builder Jenkins plugin [ghprb-plugin] there is
a hidden option `Cancel build on update` that seems to work fine.
e.g.

   1.

   I make a PR
   2.

   ghprb-plugin triggers  beam_PreCommit_PythonLint_Commit
   3.

   I make a new commit to the PR

   4.

   ghprb-plugin aborts the previous `beam_PreCommit_PythonLint_Commit` and
   adds to the queue the new one with updated sha1.



This option seems to significantly improve the experience with build
triggering and we are planning to enable it shortly.

However, putting a phrase “Run PythonLint PreCommit” in the comment
triggers new `beam_PreCommit_PythonLint_Phrase` build, but does not touch
already queued or running `beam_PreCommit_PythonLint_Commit` builds, that
are technically speaking, different jobs.

For testing purposes I made a single job which was a “_Commit” job with
added “Trigger phrase” and it works well (commit builds cancelled after
putting phrase comment in PR)

Hence my question: do we need separate “_Phrase” and “_Commit” jobs?

BR
Tobiasz

Re: [ANNOUNCE] New PMC Member: Alexey Romanenko

[Tobiasz Kędzierski]

Congratulations!

On Fri, Jun 19, 2020 at 11:39 AM Etienne Chauchot 
wrote:

> Congrats Alexey !
>
> Well deserved !
>
> Etienne
> On 17/06/2020 16:30, Gleb Kanterov wrote:
>
> Congratulations! Thanks for your hard work
>
> On Wed, Jun 17, 2020 at 1:11 PM Alexey Romanenko 
> wrote:
>
>> Thank you Ismaël and everybody!
>> Happy to be a part of Beam community!
>>
>> On 17 Jun 2020, at 09:31, Jan Lukavský  wrote:
>>
>> Congrats Alexey!
>> On 6/17/20 9:22 AM, Reza Rokni wrote:
>>
>> Congratulations!
>>
>> On Wed, Jun 17, 2020 at 2:48 PM Michał Walenia <
>> michal.wale...@polidea.com> wrote:
>>
>>> Congratulations!
>>>
>>> On Tue, Jun 16, 2020 at 11:45 PM Rui Wang  wrote:
>>>
>>>> Congrats!
>>>>
>>>>
>>>> -Rui
>>>>
>>>> On Tue, Jun 16, 2020 at 2:42 PM Ankur Goenka  wrote:
>>>>
>>>>> Congratulations Alexey!
>>>>>
>>>>> On Tue, Jun 16, 2020 at 2:41 PM Thomas Weise  wrote:
>>>>>
>>>>>> Congratulations!
>>>>>>
>>>>>>
>>>>>> On Tue, Jun 16, 2020 at 1:27 PM Valentyn Tymofieiev <
>>>>>> valen...@google.com> wrote:
>>>>>>
>>>>>>> Congratulations!
>>>>>>>
>>>>>>> On Tue, Jun 16, 2020 at 11:41 AM Ahmet Altay 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Congratulations!
>>>>>>>>
>>>>>>>> On Tue, Jun 16, 2020 at 10:05 AM Pablo Estrada 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Yooohooo! Thanks for all your contributions and hard work Alexey!:)
>>>>>>>>>
>>>>>>>>> On Tue, Jun 16, 2020, 8:57 AM Ismaël Mejía 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Please join me and the rest of Beam PMC in welcoming Alexey
>>>>>>>>>> Romanenko as our
>>>>>>>>>> newest PMC member.
>>>>>>>>>>
>>>>>>>>>> Alexey has significantly contributed to the project in different
>>>>>>>>>> ways: new
>>>>>>>>>> features and improvements in the Spark runner(s) as well as
>>>>>>>>>> maintenance of
>>>>>>>>>> multiple IO connectors including some of our most used ones
>>>>>>>>>> (Kafka and
>>>>>>>>>> Kinesis/Aws). Alexey is also quite active helping new
>>>>>>>>>> contributors and our user
>>>>>>>>>> community in the mailing lists / slack and Stack overflow.
>>>>>>>>>>
>>>>>>>>>> Congratulations Alexey!  And thanks for being a part of Beam!
>>>>>>>>>>
>>>>>>>>>> Ismaël
>>>>>>>>>>
>>>>>>>>>
>>>
>>> --
>>> Michał Walenia
>>> Polidea <https://www.polidea.com/> | Software Engineer
>>> M: +48 791 432 002 <+48791432002>
>>> E: michal.wale...@polidea.com
>>> Unique Tech
>>> Check out our projects! <https://www.polidea.com/our-work>
>>>
>>
>>

-- 

Tobiasz Kędzierski
Polidea <https://www.polidea.com/> | Junior Software Engineer

E: tobiasz.kedzier...@polidea.com
[image: Polidea] <https://www.polidea.com/>

Check out our projects! <https://www.polidea.com/our-work>
[image: Github] <https://github.com/Polidea> [image: Facebook]
<https://www.facebook.com/Polidea.Software> [image: Twitter]
<https://twitter.com/polidea> [image: Linkedin]
<https://www.linkedin.com/company/polidea> [image: Instagram]
<https://instagram.com/polidea> [image: Behance]
<https://www.behance.net/polidea> [image: dribbble]
<https://dribbble.com/polideadesign>

Re: Fwd: [DISCUSSION] Use github actions for python wheels ?

[Tobiasz Kędzierski]

Hi,

I've added some important updates to
https://github.com/apache/beam/pull/11877 and I wanted to share some
thoughts with you about possible improvements:

During releasing a new version of Beam the script
*build_release_candidate.sh* is executed. It builds sources and puts them
into the GCS staging bucket where they are consumed by separate repository
CI jobs (beam-wheels). Then they are downloaded and processed by
*sign_hash_python_wheels.sh* script.

By using github actions this process could be simplified as follows:
1. Within *build_release_candidate.sh* *release* and *release candidate*
branches are pushed to the remote repository (this is done by it now).
2. gh-actions will build sources and wheels based on these branches.
3. *build_release_candidate.sh* could verify status of the build by using
github api and corresponding data (name of the branch, commit hash) and
after successful build download sources and wheel files from gh-action
artifacts and use them in further actions.

Happy to know your opinion on this

BR
Tobiasz Kędzierski

On Mon, Jun 1, 2020 at 11:02 PM Ahmet Altay  wrote:

> > @Ahmet Altay  happy to understand the extent of what
> you had in mind, maybe the extensions are not as important to plan out, as
> they're straightforwardly bolted on (ex: daily builds).  More tactically
> would be valuable to ensure I understand what all needs to occur.  Any
> other source of info to consume other than
> https://github.com/apache/beam-wheels and
> https://beam.apache.org/contribute/release-guide/.
>
> I added a bit more details to
> https://issues.apache.org/jira/browse/BEAM-9388 as a comment, so that it
> is preserved in the JIRA. Thank you all for working on this.
>
> On Mon, Jun 1, 2020 at 9:20 AM Kamil Wasilewski <
> kamil.wasilew...@polidea.com> wrote:
>
>> "unistd.h" C header is present on POSIX systems (MacOS and Linux), but
>> not on Windows, therefore you can't build a wheel for Windows.
>>
>> I took a look and "statesampler_fast.pyx" uses "unistd.h" only because of
>> the `usleep` function. Unless we use C++ which offers [1], the solution
>> would be to search for the equivalent of `usleep` that works on Windows.
>>
>
> +Robert Bradshaw  +Valentyn Tymofieiev
>  - Do you have any suggestions on how building
> wheels could work on Windows?
>
>
>>
>> [1] https://en.cppreference.com/w/cpp/thread/sleep_for
>>
>

Re: Fwd: [DISCUSSION] Use github actions for python wheels ?

[Tobiasz Kędzierski]

Hi everyone,

Austin Benett I would like cooperate with you with introducing GitHub actions 
for python wheels.

Since last week I am trying to figure out how to do this and I was able to 
build wheels for Linux and MacOS with help of 
https://github.com/joerick/cibuildwheel/ 
.

I’ve created draft PR to apache/beam: https://github.com/apache/beam/pull/11877 
 and you can check GitHub actions 
logs on fork PR here:
https://github.com/TobKed/beam/pull/3 

I am struggling with building wheels for Windows due to the error:
> Cannot open include file: 'unistd.h': No such file or directory

caused by file sdks/python/apache_beam/runners/worker/statesampler_fast.pyx
Adding this file to be excluded by cythonize method in setup.py allowed build 
to be completed however I don’t think it is a solution.
Mentioned error on GitHub actions: 
https://github.com/TobKed/beam/runs/727709583?check_suite_focus=true#step:7:977 

 and my local PR: https://github.com/TobKed/beam/pull/2 


What do you think about it?

Tobiasz



On 2020/05/30 20:53:51, Austin Bennett  wrote: 
> There seems to be support here for this idea.  After digging through> 
> things, I *think* I understand the moving pieces and can address (reason I> 
> was digging through the code, including beam-wheels repo [1]).  Though, not> 
> 100% that I have not overlooked bits.> 
> 
> Would be happy to pickup> 
> https://issues.apache.org/jira/browse/BEAM-9388 (imagine> 
> would get to it over the course of a month or few -- so also wouldn't want> 
> to take it on if others would be looking to do it sooner) -- seems> 
> worthwhile to reduce manual steps for the release process, as well as the> 
> additional implications (daily builds) if can easily manage.  I have some> 
> experience with GitHub Actions, but not with our (BEAM) deployment/release> 
> process, nor much with building wheels.  I assume there are sufficient docs> 
> available to go through for the mechanics of the latter.  If picking up> 
> this issue, I suspect may need to bother some of those that have done> 
> recent releases -- that would best occur on the jira ticket, once at that> 
> point?> 
> 
> @Ismail -- given your experience with GitHub actions,> 
> any reason to think GitHub Actions not appropriate/ready for this specific> 
> task?> 
> 
> @Ahmet Altay  happy to understand the extent of what you> 
> had in mind, maybe the extensions are not as important to plan out, as> 
> they're straightforwardly bolted on (ex: daily builds).  More tactically> 
> would be valuable to ensure I understand what all needs to occur.  Any> 
> other source of info to consume other than> 
> https://github.com/apache/beam-wheels and> 
> https://beam.apache.org/contribute/release-guide/.> 
> 
> Also, open to the thought that this might be taking on too much, without> 
> more experience with the release process and such.  Do advise...?> 
> 
> 
> [1]> 
> https://lists.apache.org/thread.html/r93884eb080297647207f7d2b8a393e224029fc2c3509017886e84051%40%3Cdev.beam.apache.org%3E>
>  
> 
> 
> 
> -- Forwarded message -> 
> From: Ismaël Mejía > 
> Date: Wed, Feb 26, 2020 at 12:09 PM> 
> Subject: Re: [DISCUSSION] Use github actions for python wheels ?> 
> To: dev > 
> 
> 
> +1 I have been migrating multiple projects into github actions recently and> 
> even if for some tasks it is not as mature and polished as travis it has> 
> proven to be way more reliable.> 
> 
> 
> On Wed, Feb 26, 2020 at 7:07 PM Ahmet Altay  wrote:> 
> 
> > I created https://issues.apache.org/jira/browse/BEAM-9388 to explore> 
> > this. To be explicit and not to do cookie licking, I would not be able to> 
> > work on this at the moment. If anyone is interested please take it.> 
> > Otherwise I will try to come back and explore this when I can.> 
> >> 
> > On Tue, Feb 25, 2020 at 2:57 PM Robert Bradshaw > 
> > wrote:> 
> >> 
> >> I'd be in favor of this, assuming it actually simplifies things.> 
> >> 
> >> 
> > This is also my concern. I do think that it will simplify things, but I am> 
> > not certain as I am not very familiar with the github actions.> 
> >> 
> >> 
> >> (Note> 
> >> that the wheels are for several variants of linux, presumably we could> 
> >> do cross-compiles. Also, manylinux is a "minimal" linux specifically> 
> >> built as to produce shared object libraries compatible with a wide> 
> >> variety of distributions--we can't just assume that a shared object> 
> >> library built on one modern linux will just work on another. (But> 
> >> maybe it's sufficient to do this within a docker environment?)> 
> >>> 
> >> 
> > There will be no change in this area. Both in Both Travis and github> 
> > actions offer a comparable set of options.> 
> >> 
> >> 
> >>> 
> >> On Tue, Feb 25, 2020 at