You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 😄
The text was updated successfully, but these errors were encountered:
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.
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
andGithub Actions
-CircleCI
was removed simply for reasons of consolidating/rationalizing the pipelinesDeciding 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 theenvoyproxy
orgAny 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)
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 😄
The text was updated successfully, but these errors were encountered: