[WIP] repo: Sync openssl project on push to `release/v1.28`

[phlax]

Commit Message: Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional API Considerations:]

[phlax]

cc @jwendell @tedjpoole this setup assumes that you have a workflow in .github/workflows/envoy-sync.yaml on the main branch (which accepts a branch input)

it also requires that the envoy sync app has permission to trigger a workflow in the openssl repo

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[tedjpoole]

@phlax Sorry about the delay getting this finished up; I'm back looking at it again now.

What is the sequencing requirement for this? Do I need to have the "receiving end" in envoy-openssl implemented & working before this PR can be merged? I don't want to cause errors in the upstream envoy CI just because I've got something failing or missing at the envoy-openssl end.

[phlax]

What is the sequencing requirement for this?

i think the two things required to make it work are:

• the relevant bot (ie github app) is given workflow trigger permissions in the openssl repo - i can do this if/when we are ready to land it
• on the openssl repo side there needs to be a dispatchable workflow with the name envoy-sync.yml

[phlax]

see here for an example workflow:

https://github.com/envoyproxy/go-control-plane/blob/main/.github/workflows/envoy-sync.yaml

[tedjpoole]

One problem I can see in this scenario is that the .github/workflows/envoy-sync.yaml file is overloaded. The same file name will exist in both the envoy and envoy-openssl repositories, but will have a different purpose & content in each repository.

Since envoy-openssl is effectively just a clone of envoy with just a few extra bits, it will also have a .github/workflows/envoy-sync.yaml file, but in the envoy-openssl repo we need that file to perform the "receiving logic" rather than the "sending" logic. Therefore, each time we sync, we would have to deal with the conflicts that would arise between the upstream content and the downstream content of that file. Alternatively the downstream version of that file could implement some logic to save itself, then sync, and then restore itself etc.

To avoid this situation, would it be possible to change the name of the downstream workflow being invoked, from envoy-sync.yaml to something like envoy-sync-downstream|target|receive.yaml instead to avoid the overload?

[phlax]

... would it be possible to change the name of the downstream workflow being invoked, from envoy-sync.yaml

for sure - i see the issue - it would at least be confusing if not incorrect - but this shouldnt be a problem - we can just give it a different name

[tedjpoole]

@phlax could you do a sanity check on what I've implemented for the receiving end in envoyproxy/envoy-openssl#247 please.

[phlax]

hi - yep - looks good - reviewed there

i think we will need to adjust this pr if we want to trigger on branches other than 1.28

[tedjpoole]

Can we also include the release/v1.31 and main branches please.