feat: sync secrets GitHub environments

[nimish-ks]

🔍 Overview

Added support for syncing secrets to GitHub repository environments.

Addresses - #647
Docs - phasehq/docs#189

💡 Proposed Changes

Added the ability to select a GitHub environment for a given repository and sync secrets to it.

🖼️ Screenshots or Demo

Select an destination Environment on GitHub

Sync status now indicates the destination environment on GitHub

Manage sync popover now indicates the destination environment on GitHub

Secrets synced to GitHub Environments

❓ Open Questions

• If a given environment doesn't exist on a given repo should we create it? Is this possible with the OAuth token permission we currently have? What if we were to switch away from OAuth tokens to PAT?
• Secrets in Phase are currently being sync to GitHub Environments as type 'Secrets'. This design decision is mainly for security reasons. However, given Phase is also a versatile configuration management platform, should we also add support for the 'Environment variables' type?

🧪 Testing

• Set up a GitHub repository with environments and sync secrets to it
• Attempt syncing secrets to the same repo directly (not the environments)

🎯 Reviewer Focus

• The bulk of the syncing logic is in actions.py
• Pay close attention to what public key (Repository / Environment) we are wrapping the secrets with before syncing it with GitHub repo
• Make sure existing sync, third party integration credentials and related metadata isn't broken by this change

💚 Did You...

• Regenerate graphql schema and types (if required)
• Verify the app builds locally?
• Manually test the changes on different browsers/devices?

[m-braha]

Awesome, this looks great!

For the open questions:

• Having Phase (optionally) create the GitHub environment is a nice to have, but it's not a deal breaker if it's missing.
• My approach with configuration items vs secrets has been: Since Phase now has all the secrets, we can commit files with non-secret config values directly to our repos. There is a non-zero overhead to using values in Phase (as intended, we want that bit of overhead around secrets) and from a DevEx point of view, files directly in the repo are easiest for developers. But it does mean deployments need to fetch from multiple places instead of just Phase. There are people at my company who feel the opposite and we should put everything in Phase. It would be interesting to know what other companies do.

[scheibling]

I've built this locally and done a short test run, so far I haven't managed to break anything (apart from parts of the build process, I'll put that in a separate issue)

Regarding the open questions:

• I agree with m-braha, creating the environment is a nice-to-have (if optional), but generally when creating an environment there is more configuration involved than just the name which has to be done on the Github side anyway, so I wouldn't consider it a priority

• As long as it's clearly marked/warned that they will be synced into Github in clear text (I can think of a few juniors that would have a tendency to not notice that small detail) that would undoubtedly also be a nice-to-have. As a practice, we'd generally put everything in secrets to not have to consider how sensitive something is, since we are able to see/edit them in-place in Phase opposed to Github where they have to be overwritten.

Thanks for your work on this, much appreciated!

[Copilot]

Pull Request Overview

This PR adds support for syncing secrets to GitHub repository environments, expanding the existing GitHub Actions integration to target specific environments rather than just repository-level secrets.

• Added optional environment selection in the GitHub sync configuration UI
• Extended the GraphQL schema and mutations to support environment-specific syncing
• Updated backend logic to handle both repository-level and environment-level secret synchronization

Reviewed Changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
frontend/graphql/queries/syncing/github/getEnvironments.gql	New GraphQL query to fetch GitHub environments for a repository
frontend/graphql/mutations/syncing/github/CreateGhActionsSync.gql	Updated mutation to include optional environmentName parameter
frontend/components/syncing/ServiceInfo.tsx	Enhanced display to show target environment in sync status
frontend/components/syncing/GitHub/CreateGhActionsSync.tsx	Added environment selection UI with repository dependency
frontend/components/syncing/CreateSyncDialog.tsx	Minor styling adjustment for padding
frontend/apollo/schema.graphql	Updated GraphQL schema with new environment-related fields
frontend/apollo/graphql.ts	Generated TypeScript types for new GraphQL operations
frontend/apollo/gql.ts	Updated GraphQL document mappings
backend/backend/schema.py	Added GitHub environments query resolver
backend/backend/graphene/queries/syncing.py	Added resolver function for fetching GitHub environments
backend/backend/graphene/mutations/syncing.py	Updated mutation to handle optional environment parameter
backend/api/utils/syncing/github/actions.py	Enhanced with environment-specific API calls and secret management
backend/api/tasks/syncing.py	Updated sync task to pass environment parameter

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[nimish-ks]

Awesome, this looks great!

For the open questions:

* Having Phase (optionally) create the GitHub environment is a nice to have, but it's not a deal breaker if it's missing.

* My approach with configuration items vs secrets has been: Since Phase now has all the secrets, we can commit files with non-secret config values directly to our repos. There is a non-zero overhead to using values in Phase (as intended, we want that bit of overhead around secrets) and from a DevEx point of view, files directly in the repo are easiest for developers. But it does mean deployments need to fetch from multiple places instead of just Phase. There are people at my company who feel the opposite and we should put everything in Phase. It would be interesting to know what other companies do.

The most common approach would be to keep secrets and configurations in Phase. Secrets and configuration should be thought of in two dimensions - Keys and Environments. An engineer should quickly able to answer - for a given environment x does key y exist? If yes, what's the value?

Tracking everything in one place would have some up-front cost but long term benefits. Think of it has getting folks to start using version control early in their career haha