DEVPROD-27645 Add workflow to sync GraphQL schema to UI repo

[khelif96]

Summary

• Adds a new GitHub Actions workflow that automatically opens a PR in evergreen-ci/ui when GraphQL schema files (graphql/schema/**) change on main
• The workflow clones the UI repo, creates sdlschema symlinks, runs pnpm codegen, and opens a PR with the updated generated TypeScript types
• Handles deduplication by updating an existing open PR instead of creating duplicates

Test plan

• Configure EVERGREEN_UI_TOKEN secret in repo settings with appropriate permissions on evergreen-ci/ui
• Merge a schema change to main and verify the workflow triggers
• Confirm a PR is created in evergreen-ci/ui with updated types.ts files
• Verify that a subsequent schema change updates the existing PR rather than creating a duplicate

🤖 Generated with Claude Code

[hadjri]

LGTM, was this workflow verified / tested?

[khelif96]

LGTM, was this workflow verified / tested?

Its kind of hard to test the workflow since it involves creating prs on merges to main where only a diff on graphql schemas from opposite repos but according to my top agent and all of his friends (opus 4.6) It is supposed to work

[sophstad]

This does feel like the idealized solution but I'm not 100% sure that it addresses the problems with our workflow. Imo the main issues are:

1. Slow signal on updating generated types when a PR touches GraphQL
2. Irrelevant signal when a PR does not

This seems to mostly solve for a third problem, "generated types are out of date and breaking things." We encounter that occasionally, mostly when non-UI engineers make changes (e.g. admin settings), but not too often. We've also been delinquent with automated PRs lately and I fear would be yet another chore that is tough to stay on top of.

Interested in your thoughts! Definitely not opposed to trying this out 😇

[khelif96]

This does feel like the idealized solution but I'm not 100% sure that it addresses the problems with our workflow. Imo the main issues are:

1. Slow signal on updating generated types when a PR touches GraphQL
2. Irrelevant signal when a PR does not

This seems to mostly solve for a third problem, "generated types are out of date and breaking things." We encounter that occasionally, mostly when non-UI engineers make changes (e.g. admin settings), but not too often. We've also been delinquent with automated PRs lately and I fear would be yet another chore that is tough to stay on top of.

Interested in your thoughts! Definitely not opposed to trying this out 😇

I think it might at least reduce the signal if not eliminate it when paired with the other pr.

1. Slow signal on updating generated types when a PR touches GraphQL

The change in the other pr should still require regenerating types if graphql changes in the UI so we should still get signal but only when its relevant. If there are no graphql changes this pr ensure the types in the UI repo are up to date.

2. Irrelevant signal when a PR does not

This change ensures that the UI always has the latest types (assuming the engineer started their branch off of a recent main branch rebase. So there will never be a codegen needed signal since the types should always be up to date

We encounter that occasionally, mostly when non-UI engineers make changes (e.g. admin settings), but not too often.

I encounter this a bunch :( I needed to bump types a few times in a few of my open prs last week which is what motivated this.