You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Enable CI runs on PRs coming from forks. As discussed in #236 (comment) this is currently not possible because the BuildBuddy secret cannot be exposed to actions run from forks and the run fails due to missing credentials.
Ideally, we'd find a way to configure a read-only token for actions run from forks while using a read-write token for internal runs.
Short of that, we could simply run without BuildBuddy at all for actions triggered from forks.
The text was updated successfully, but these errors were encountered:
I think we could combine the "Auth file", and read-only keys to achieve this. Perhaps have the CI try and generate a file in the CI when the read-write secrets exists, and otherwise fall-back on this read-only key that could just live in source control itself. Or have the read-only "auth-file" be the default, and have the CI overwrite it when the read-write one is available?
This workflow will use the cache, without uploading the local results to
BuildBuddy. This should avoid the error we currently get when a API key
isn't supplied to the job.
Ref: #243
Enable CI runs on PRs coming from forks. As discussed in #236 (comment) this is currently not possible because the BuildBuddy secret cannot be exposed to actions run from forks and the run fails due to missing credentials.
Ideally, we'd find a way to configure a read-only token for actions run from forks while using a read-write token for internal runs.
Short of that, we could simply run without BuildBuddy at all for actions triggered from forks.
The text was updated successfully, but these errors were encountered: