Hi, Flink Team,
According to the discussion, I assume that we are now agree that running
cron job for ARM at this moment. I have ran POC e2e test in OpenLab for
some days[1]. It includes:
flink-end-to-end-test-part1
split_checkpoints.sh and split_sticky.sh
flink-end-to-end-test-part2
Hi Till
Thanks for your response. All ARM related work is triggered here:
https://issues.apache.org/jira/browse/FLINK-13448 and I have created some
PRs already.
After do some hacking locally, E2E tests runs well now. I have added
them into OpenLab alreay. The POC log:
This sounds good Xiyuan. I'd also be in favour of running the ARM builds
regularly as cron jobs and once we see that they are stable we could run
them for every master commit. Hence, I'd say let's fix the above mentioned
problems and then set the nightly cron job up.
Cheers,
Till
On Fri, Sep 20,
Sure, we can run daily ARM job as Travis CI nightly jobs firstly. Once
it's stable enough, we can consider adding it to peer PR.
BTW, I tested flink-end-to-end-test on ARM in last few days. Keeping the
same as Travis, all 7 scenarios were tested:
1. split_checkpoints.sh
2. split_sticky.sh
3.
My gut feeling is that having a CI that only runs on a specific command
will not help too much.
What about going with nightly builds then? We could set up the ARM CI the
same way as the Travis CI nightly builds (cron builds). They report build
failures to "bui...@flink.apache.org".
Maybe Chesnay
The ARM CI trigger has been changed to `github comment` way only. It means
that every PR won't start ARM test unless a comment `check_arm` is added.
Like what I did in the PR[1].
A POC for Flink nightly end to end test job is created as well[2]. I'll
improve it then.
Any feedback or question?
Before ARM CI is ready, I can close the CI test for each PR and let it only
be triggered by PR comment. It's quite easy for OpenLab to do this.
OpenLab have many job piplines[1]. Now I use `check` pipline in
https://github.com/apache/flink/pull/9416. The job trigger contains
github_action and
Adding CI builds for ARM makes only sense when we actually take them into
account as "blocking a merge", otherwise there is no point in having them.
So we would need to be prepared to do that.
The cases where something runs in UNIX/x64 but fails on ARM are few cases
and so far seem to have been
Sorry, maybe my words is misleading.
We are just starting adding ARM support. So the CI is non-voting at this
moment to avoid blocking normal Flink development.
But once the ARM CI works well and stable enough. We should mark it as
voting. It means that in the future, if the ARM test is failed
I'm sorry, but if these issues are only fixed later anyway I see no
reason to run these tests on each PR. We're just adding noise to each PR
that everyone will just ignore.
I'm curious as to the benefit of having this directly in Flink; why
aren't the ARM builds run outside of the Flink
Thanks for Stephan to bring up this topic.
The package build jobs work well now. I have a simple online demo which is
built and ran on a ARM VM. Feel free to have a try[1].
As the first step for ARM support, maybe it's good to add them now.
While for the next step, the test part is still
I'm wondering what we are supposed to do if the build fails?
We aren't providing and guides on setting up an arm dev environment; so
reproducing it locally isn't possible.
On 23/08/2019 17:55, Stephan Ewen wrote:
Hi all!
As part of the Flink on ARM effort, there is a pull request that
Hi all!
As part of the Flink on ARM effort, there is a pull request that triggers a
build on OpenLabs CI for each push and runs tests on ARM machines.
Currently that build is roughly equivalent to what the "core" and "tests"
profiles do on Travis.
The result will be posted to the PR comments,
13 matches
Mail list logo
