[Resolver] Support custom env vars for Openhands agents
End-user friendly description of the problem this fixes or functionality that this introduces
- [ ] Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below
Give a summary of what the PR does, explaining any non-trivial design decisions
This PR allows users to pass custom env variables to the openhands runtime. This is tough to achieve in Github actions natively as Github doesn't allow for dynamic manipulation of secrets. How this PR works -
- User creates a repo secret with the prefix
OPENHANDS_ENV_ - ALL secrets are passed to the reusable workflow
- Secrets are filtered by prefix
OPENHANDS_ENV_and replaced withSANDBOX_ENV_(this allows openhands agents to have access to env vars in its runtime)
Pros/Cons
This is quite simple for the user to setup. The downside is ALL secrets are passed to the reusable workflow, which isn't ideal in terms of granularity.
Sample Test
Issue addressed - This issue requires openhands to run an api with the custom env variable. Openhands would fail unless the env var exists in its runtime. Workflow logs
Alternative approaches
1: Filter before sending
- The caller workflow would require a separate job to filter secrets by prefix (the "
env job") - The caller would encrypt the secrets
env jobwould pass the encrypted value (through its output, which makes the encrypted value visible) to the job which invokes the reusable workflow- The reusable workflow is invoked with the encrypted secrets
- Reusable workflow will decrypt the secrets and pass them to
Openhands
We need an encryption scheme as github actions don't support a native way to pass secrets between jobs (and filtering secrets cannot be performed inside the job calling the reusable workflow).
I'm thinking symmetric key encryption using GNU Privacy Guard would work to achieve this. The user would need to perform just one additional step to setup a PASSPHRASE in their repo secrets.
2: Key store
Add support for custom env vars via integrations to external key stores. For example, AWS Secrets Key manager.
Link of any specific issues this addresses #5132