-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
testing: Add support for runtime environment variables to GitHub Workflows #3501
Comments
Here are some notes towards Option 2 from the OP: Illustrating the thought just a bit further (this is a thought experiment, not tested!) in functions-v2-imagemagick.yaml: Add a new job:
Add use of this to the test job:
In test.yaml add a new input:
Then after the authentication step, load the environment from input to env:
If some variant of this works, we now have a way for the calling workflow to pass unexpected environment variables to the test workflow. |
Just FYI, we may not be blocked, as this capability already exists in the workflow generator, with several samples using this workflow. This ticket could cover potential refactorings if needed. |
Ah, thank you for pointing this out. I saw a couple examples of the samples using the workflow-secrets template but I interpreted them as one-off forks of the reusable I don't have access to review the existing secrets, but there is notionally a limit of 100 per repo: https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#limits-for-secrets. This opens three tracks for this issue:
The advantage of the approach proposed in this issue is it helps reduce structural variation in the individual workflows, meaning we may have more flexibility in the future to group tests or apply matrix strategies. I'm happy to move forward with #3149 via the workflow-secrets template in the meantime. |
GitHub Workflows is the preferred test driver for tests in this repository, but the current workflow implementation has several limitations. One of them is the ability to set runtime environment variables that are specific to a Workflow.
Approach
Options:
Option 2 is the most versatile with the least need to refactor existing code.
Option 1 has the further downside of placing test-specific parameters in a central file. I'm not sure if any changes to
test.yml
are triggering wide-scale test execution currently, but with this approach we'd likely need to trigger more tests from any change, which would include adding environment variables for unrelated tests.@pattishin has asked that as part of the PR fixing this issue, we look for existing hard-coded values and shift them to environment variable configuration.
This issue is a blocker on implementation of GHA-based test workflows for a number of samples, with #3149 as the driver for research today.
The text was updated successfully, but these errors were encountered: