Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Decide on preferred CI provider across Envoy projects #14154

Closed
phlax opened this issue Nov 23, 2020 · 2 comments
Closed

[RFC] Decide on preferred CI provider across Envoy projects #14154

phlax opened this issue Nov 23, 2020 · 2 comments
Labels
area/build stale stalebot believes this issue/PR has not been touched recently

Comments

@phlax
Copy link
Member

phlax commented Nov 23, 2020

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 😄

@phlax phlax added the triage Issue requires triage label Nov 23, 2020
@zuercher zuercher added area/build and removed triage Issue requires triage labels Nov 24, 2020
@github-actions
Copy link

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.

@github-actions github-actions bot added the stale stalebot believes this issue/PR has not been touched recently label Dec 24, 2020
@github-actions
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/build stale stalebot believes this issue/PR has not been touched recently
Projects
None yet
Development

No branches or pull requests

2 participants