You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 27 Next »

Date, Time & Location

UTC time 1700 hrs
Meeting space meet.apache.org - https://meet.apache.org/buildsmeeting20210114
Backup meeting space - http://meet.google.com/mfq-gajx-wmt - To go to if our Jitsi instance crashes on us.

Attendees (Add your cwiki name below)

This event is open to all committers and guests

Format

The meeting is yours to discuss whatever you want to. Aim to discuss with 'each other' as 
in others subscribed to the builds@ mailing list, from your project or from other projects.

There will also be Infra representation for infra related discussion items. I'd like to be clear 
though, this is an informal meeting arranged for the benefit of individuals and projects to 
talk about anything they like in relation to the ASF Build services and related integrations,
and is not a projects vs infra panel discussion.

Topics of interest

Add here anything you would like a chance to talk about this week.

Please note that the primary focus of this meeting is to talk about Foundation-related needs, rather than public needs. Keep this in mind when speaking with our GitHub guest.


ItemWhoNotes
Action Items from last meeting
Github EnvironmentsGavin McDonald

Daily Statistics - At least daily snapshots if not live updates for things like, how many runners we have in use, which project is using them, how many minutes / hours a build takes etc. 

Is there an ETA to make this stats available via a Public API?

Gavin McDonald
GitHub Actions Brian Douglas
(Github Actions) Performance + related -> self-hosted runners for public repos.

We badly need to be able to run securely self-hosted runners for our repos but we can not because it's not secure for builds run from forks (anyone can inject any of their code in a PR). We proposed a PR to GA runner (beginning of November) to allow configuration to limit the self-hosted runners to only allow jobs from committers/main repo - but not allow them for forks. That would solve the vast majority of the issues as we have funding for the self-hosted runners. We can run our own "fork" of the runners (we are actually building this capability), however, we have to go through extra hoops (including automated rebasing of our changes on top of latest changes from GitHub) but this is not a stable solution and we do not know if it is secure enough. We need GitHub approved solution and we are willing to have only a subset of the jobs run there. We would love to have a GitHub 'blessed' solution. 
https://github.com/actions/runner/pull/783

(Github Actions) Security vulnerabilities reported via bounty.github.com ( I do not want to describe details at public page)


We reported two security vulnerabilities that we think are in Github Actions. The issues caused infrastructure to disable parts of Github Actions functionalities for all ASF projects, but some of us think those are issues that are affecting not only ASF projects but others as well. We would love to hear if GitHub acknowledges those issues and what are the plans about it.

https://hackerone.com/bugs?subject=user&report_id=1068831

https://hackerone.com/bugs?subject=user&report_id=1068843

Corollary to above - can self hosted runners exfiltrate org-wide Actions secrets?Fluxo Lambertus

Enabling Github Container Registry

We keep on getting random errors when we push images to GitHub Psckage Registry related to manifest version (they cause pushed images are unusable). This has been reported in the past to GitHub support and the answer we got that those are inherent problems with Github Package Registry which is essentially deprecated and we should migrate to the new Github Container Registry which has better infrastructure and is now a recommended solution as per this blog. In order to get a stable CI we need to have also stable container registry as this is essential for build optimizations we implemented.

The  INFRA-20959 has all the details. Is there anything stopping INFRA from enabling the registry and is it really the only solution from GitHub that we can get.


UPDATE. This problem started to hit us hard today. Even with self-hosted runners we try and with implementing some workaround, we have every workflow has at least one job failing today on pushing to GitHub Registry. GitHub support acknowledged the issue and looking at it, so there is hope I will be able to tell more about it at the meeting.

Better/smarter GHA allow/deny lists

It would be helpful for our organization if we could set a rule that all external action references (allowed ones like actions/* and apache/* aside) had to be pinned to their 40-char SHA hash. Currently we are only able to sort of pin with an experimental cropped glob, so either allowing longer globs or having a shortcut for "a 40 character hexadecimal value" would be appreciated greatly.



Speaking of Foundation needs, this might be a good visualisation showing current state of all ASF projects using Github Actions:

This Graph shows chart of workflows (not jobs) in progress for all ASF projects for the last two weeks:

Compare it with beginning of December:


Meeting Notes

Action Items

Next Meeting



  • No labels