description

Envoy has pretty complex needs when it comes to CI, and uses quite a lot of resources.

It can also take up a lot of developer time in term of debugging and adding to CI

Current the Envoy project uses Azure and Github Actions - CircleCI was removed simply for reasons of consolidating/rationalizing the pipelines

Deciding on a long term strategy regarding CI - and potentially consolidating towards some preferred choice/s would make life easier for the community and make development easier to document

If the choice of CI was good (8)) then it could potentially reduce wait/debug cycles for all developers/contributors.

There is also an ACL dimension here in terms of starting/stopping/restarting monitoring builds

And an artifact dimension in terms of caching/publishing arttifacts and time/reliabiltiy there

Caching proxies for popular repos - eg brew/apt/pip/npm would possibly help in terms of speeding things up

This is also something the community could help with in terms of providing CI resources

This is an issue which affects not just the envoy repo but other/new repos hosted within the envoyproxy org

Any solution is likely to need to be agile - ie allow for farming out workloads to other providers where required - but if we can decide on/doc defaults it would be great as a target to move towards

Some options (non-preferentially thrown into the ring)

• a hosted jenkins solution
  • very configurble
  • (yay 🐧 friends)
• move towards azure
  • envoy uses this mostly already
  • does most of what we need - if it aint broke...
• move towards gh actions
  • in terms of underlying ownership/infra (im guessing) this is the same as azure - so just more limited (i might be wrong)

no decisions need to be set in stone, but if we had a "for now" target it would make documenting and decisions around this easier

rfc

offers of :supercomputer: access and redundant bitcoin networks most welcome 😄