Hi, Ticket: https://issues.apache.org/jira/browse/AVRO-3242 Pull Request: https://github.com/apache/avro/pull/1380 Build results: https://app.travis-ci.com/github/apache/avro/builds/240559221
Regards, Martin On Wed, Oct 20, 2021 at 9:48 AM Martin Grigorov <[email protected]> wrote: > Hi, > > I've found a way to use Github Actions self-hosted runners (SHR) for > public repos securely: > https://github.blog/changelog/2021-07-01-github-actions-new-settings-for-maintainers/ > Before I start working on the TravisCI config I wanted to check the GHA > one with you. > > What is the problem with GHA SHR: the issue is that an evil person could > add/edit a GHA workflow in such a way that it does bad things. > This is not a problem with the default runners because they are VMs > instantiated just for the workflow job and then discarded. > > With "Require approval for all outside collaborators" this issue is not a > problem because each Pull Request will have to be explicitly approved by an > Avro project member before its checks being executed. > Currently the project uses "Require approval for first-time contributors", > i.e. a project member has to enable the checks only once per contributor. I > think this option could not be used because the evil person could create > one good PR to be approved and then a following PR with bad intention. > > So, what do you prefer - TravisCI or GHA+approvals ? > > For GHA SHR we could use OracleCloud. Their Linux ARM64 instances are free > and the SHR setup is very easy ( > https://blogs.oracle.com/cloud-infrastructure/post/announcing-github-actions-arm-runners-for-the-arm-compute-platform-on-oracle-cloud-infrastructure > ) > > Regards, > Martin > > On Mon, Oct 18, 2021 at 12:12 PM Ryan Skraba <[email protected]> wrote: > >> Hey there! Indeed, Apache Avro used TravisCI in the past. >> >> I liked it, but our setup was a bit odd and very slow (largely due to >> how we used yetus and building the uberjar every time). I wouldn't >> recommend going back to *that* same setup, but +1 for testing on >> ARM64, especially if you can propose something lightweight! >> >> All my best, Ryan >> >> [AVRO-3009 Delete Travis / Add GitHub]: >> https://github.com/apache/avro/pull/1043 >> >> >> On Mon, Oct 18, 2021 at 10:27 AM Martin Grigorov <[email protected]> >> wrote: >> > >> > Hello Avro devs, >> > >> > What would be your opinion on introducing a second CI for Avro to >> execute >> > the build and tests on Linux ARM64 architecture ? >> > >> > Currently Avro uses GitHub Actions (GHA), which is a really nice CI >> > platform for open source projects! >> > But GHA has only x86_64 runner nodes. One could use self-hosted runners >> but >> > they are not recommended for public repositories due to security >> concerns ( >> > >> https://cwiki.apache.org/confluence/display/INFRA/GitHub+-+self-hosted+runners >> > ). >> > There are several GHA-like cloud-based CIs like CircleCI, CirrusCI and >> > DroneIO but they are not allowed by Apache Infra team because they want >> > write permissions to the repo. >> > So, the only option at the moment is TravisCI! >> > Some Apache projects have used TravisCI in the past but moved to GHA >> > because of its better experience and because at some point TravisCI was >> too >> > crouded and the wait-queue was too big. >> > The wait-time is no more a problem these days, especially for the ARM64 >> > nodes! >> > >> > In my experience most of the issues related to ARM64 in Big Data >> projects >> > was due to data serialization libraries like Protobuf and Snappy which >> use >> > native libraries and until some point they didn't come with binaries for >> > aarch64. >> > For Avro, CI on ARM64 would be beneficial mostly for the C and C++ >> modules >> > but also for the interpreted language ones, e.g. Apache Pig does not >> build >> > on ARM64 with Avro Java 1.7.7 but works fine with 1.8.2 (I didn't dig >> what >> > exactly was the cause). >> > >> > If my proposal is accepted I volunteer to do all the required work! >> > >> > Regards, >> > Martin >> >
