CI jobs

[jwendell]

We need to create CI jobs for pre-submit tests to run on every PR.

We probably don't want to run all tests that run in envoy/envoy. We need to define the subset of tests we want to run here and implement them.

Who can help us setting these jobs up?

cc @tedjpoole @phlax

[phlax]

@jwendell i can help - altho not entirely clear what is needed - feel free to ping on slack if its helpful

[tedjpoole]

As a minimum, we need x64 & arm64 builds plus runs of all tests under //test/.... Initially this is required on the release/v1.28 branch, after which we can port forward to the release/v1.30 branch.

[phlax]

i think the best thing is to set up github workflows for this

historically we used azp for the main build+test jobs, but we are (slowly) transitioning these to github workflows

the snag here is that there are no free arm runners on github - but there is a self-hosted arm pool waiting to be used in github which we can probably start using immediately

im guessing you will also want to make use of RBE as this will speed things up/reduce resource requirements - this should be relatively straight forward - happy to help with that

the other small issue with arm is that we dont currently have any RBE workers for arm - altho it is planned to add this. In Envoy we work around by using ~large arm machines and caching with bazel-remote (https://github.com/buchgr/bazel-remote)

i guess my main question is about triggering the ci - im assuming you want all PRs and pushes to relevant branches in your repo tested, but there is also the question of whether you want it to be triggered also on every change in envoy

[jwendell]

We want those jobs to run on every PR in this repo indeed (pre-submit tests). Initially for the 1.28 branch, as Ted mentioned above.

As for the changes in Envoy, what we are planning to do is to setup a sync job that will track the Envoy release branches (1.28 initially) and issue a PR in this repo, keeping our branch in sync with upstream Envoy branch. Then, pre-submit tests will run on that PR, and it can be safely merged once all tests pass.

[phlax]

re sync - ok - that can be done, esp as its not on our main branch (which would create a lot of ci).

using a PR rather than just committing adds a bit of complexity - as it needs to handle existing PRs - but not too much

[phlax]

thinking further - it also needs to handle conflict if your envoy branch != the upstream one

[jwendell]

We have been using automator.sh (used a lot in istio and maistra) script to create those PRs out of syncing branches. And yes, conflicts need to be handled manually. Automating the sync reduces the number of manual intervention.

Also, it's not clear if we need to run the sync job on every new commit in 1.28 branch, or only when we have a new tag.

[phlax]

we have a system setup already for triggering workflows in downstream repos, so triggering whatever workflow is required should be pretty easy

[phlax]

i was looking further at automator.sh - specifically i was trying to figure out how ci was being triggered - afaict that is handled by prow (https://prow.k8s.io/) - which is not something we have setup or use currently

i have opened a WIP PR (envoyproxy/envoy#34319) to add sync code that can trigger a workflow in this repo - i guess that could then call automator.sh

[phlax]

further to what i wrote above - github has just added arm runners, so this should simplify things a lot