Added envoy-sync-receive workflow

[tedjpoole]

Added envoy-sync-receive.yaml workflow. This is designed to be invoked from the envoy-sync.yaml workflow from the upstream envoyproxy/envoy repository (see envoyproxy/envoy#34319).

It performs a merge from the specified branch in upstream envoyproxy/envoy into the same named branch in envoyproxy/envoy-openssl e.g.

• envoyproxy/envoy[release/v1.28] -> envoyproxy/envoy-openssl[release/v1.28]
• envoyproxy/envoy[release/v1.30] -> envoyproxy/envoy-openssl[release/v1.30]
• envoyproxy/envoy[main] -> envoyproxy/envoy-openssl[main]

For each distinct branch name, the script manages at most 1 associated pull request and/or issue, depending on the success of the merge.

If the merge from upstream succeeds, it creates or updates the associated pull request, and closes the associated issue (if there is one).
If the merge from upstream fails, it leaves the associated pull request untouched (if there is one), and creates or updates the associated issue.

[phlax]

looks good @tedjpoole, but will need a bit of setup with the repo/s and/or bot/s

[jwendell]

Generally speaking, LGTM, just had a few nits.

I have zero idea how the workflow works, but I trust you :)

Hint: You may run shellcheck against this script, and, if you use vscode, you can install the shellcheck extension.

[jwendell]

maybe -x is too much? We're doing a few echos, isn't that enough?

[tedjpoole]

I left the -x on the assumption that (1) there probably will be some bugs to fix, and (2) the -x will make it easier to fix those bugs.

[jwendell]

We need to pay double attention to not leak any secret/token.

[jwendell]

I'm guessing gh only needs the GITHUB_TOKEN variable to be set in order to work, right? (which is defined in the job yaml file)

[phlax]

hmm, actually good point, if we are using the GITHUB_TOKEN (and setting relevant creds) we dont need the appauth stuff which essentially provides write creds

[tedjpoole]

Yes, the gh command gets its auth token from the GITHUB_TOKEN (or GH_TOKEN) environment variable (see docs).

However, it seems like the default secrets.GITHUB_TOKEN is not sufficient for our needs. It is limited to just the repository scope and cannot access projects or create/update issues etc.

@phlax would it be appropriate to pass the ${{ steps.appauth.outputs.token }} token from the upstream envoy-sync.yml workflow, as an input to the downstream envoy-sync-receive.yaml workflow?

[phlax]

It is limited to just the repository scope and cannot access projects or create/update issues etc

i think you need

permissions:
  issues: write
  pull-requests: write

creating/updating issues/prs should work with that

re appauth - i think we dont need it at all if we are using the GITHUB_TOKEN

[phlax]

(that is stil repo-scoped tho)

[tedjpoole]

Thank you! Adding the issues: write permission enabled the gh issue create and gh issue comment commands to work.

However, despite adding the pull-requests: write permission, the gh pr create command still fails to create a pull request:

++ gh pr create --head auto-merge-main --base main --title 'auto-merge envoyproxy/envoy[main] into tedjpoole/test-downstream[main]' --body 'Generated by envoy-sync-receive.sh'
pull request create failed: GraphQL: GitHub Actions is not permitted to create or approve pull requests (createPullRequest)

Also, while testing locally I encountered this error from the git push command. It seems to be caused by the fact that the merge had brought in some upstream changes to workflow files under the .github/workflows/ directory, and when pushing any changes to workflow files, github requires the actor to have workflows: write permission, which cannot be given to the secrets.GITHUB_TOKEN.

+ git push --force origin HEAD:auto-merge-main
To https://github.com/tedjpoole/test-downstream
 ! [remote rejected]       HEAD -> auto-merge-main (refusing to allow a GitHub App to create or update workflow `.github/workflows/_cache.yml` without `workflows` permission)
error: failed to push some refs to 'https://github.com/tedjpoole/test-downstream'

Therefore, it does seem that the secrets.GITHUB_TOKEN cannot be given some of the permissions that we need in the script.
I know I need to use a different token which has the additional permissions, but I'm not really sure of the best way to achieve that.

If I reinstate this step:

    - id: appauth
      uses: envoyproxy/toolshed/gh-actions/appauth@actions-v0
      with:
        key: ${{ secrets.ENVOY_CI_UPDATE_BOT_KEY }}
        app_id: ${{ secrets.ENVOY_CI_UPDATE_APP_ID }}

then I think I can use ${{ steps.appauth.outputs.value }} in place of secrets.GITHUB_TOKEN, but I'm not sure where I need to create those two secrets, or even if a am able to, nor where I can configure the permissions that are required by the script.

Any advice or pointers welcome thanks

[phlax]

lgtm, thanks @tedjpoole

nit re appauth - better to use token - see here:

https://github.com/envoyproxy/toolshed/blob/7f22091712156acf153d96e97dfd4ba9c11cb7d1/gh-actions/appauth/main.ts#L57-L59

[phlax]

workflow changes lgtm, thanks @tedjpoole

ill update the wf trigger bot now to give creds in this repo

[tedjpoole]

Tested with a GitHub App in my own account, and confirmed that it needs the following permissions:

• contents: read-write
• issues: read-write
• metadata: read
• pull requests: read-write
• workflows: read-write

Note, the workflow permission is required because the changes being synchronised from envoy into envoy-openssl sometimes include changes to workflow files i.e. the synchronisation process doesn't actually perform workflow modifications itself.