Allow external pull requests to use secret variables from the forked repo

In the light of Docker Hub: You have reached your pull rate limit.

A build, even an external pull request one, may need to use some kind of credentials. A repo maintainer providing their own, however, makes them public information because external pull requests contain untrusted code.

However, why not allow the pull request’s author to supply their credentials (e.g. by setting them as secret variables in Travis settings for their fork)? A pull request’s author supposedly does trust the upstream code to keep them safe.

  • This would naturally work only for secret variables from settings rather than from .travis.yml. This is okay because it doesn’t make sense to add secret variables to a pull request code that are encrypted with another repo’s key.
  • The suggestion is to only do this for secret variables. 'Cuz if we do this for others, it’d be possible that a variable is defined in both fork and upstream – it’s unclear what to do in such a case.
    • It’s still unclear what to do if a variable exists in upstream but as a non-secret variable.
      • Since the suggestion is intended for providing credentials, I recommend for the upstream variable to take precedence. That’s because a variable of another kind can alter build’s behavior in arbitrary ways, and in a pull request, the goal is to see how the contributed code would work in the upstream repo, with upstream repo’s settings.
  • It also makes sense to only import variables in such a way that the upstream has whitelisted. That’s to prevent a fork from setting arbitrary variables that are not set in the upstream and likewise altering the build’s behavior.
    • In this case, the above point on “only doing this for secret variables” becomes moot since the upstream’s author has explicitly allowed the variables to be overridden.

I’d say allow both secret and non-secret variables to be supplied in the fork, and not inherit either type of variable from upstream. This is because some non-secret variables are not private but still undesirable for sharing, e.g. the project names of external code-scanning platforms like Coverity or SonarCloud.

Ideally repo maintainers should document the expected variables in their .travis.yml to aid contributors’ CI-testing.

1 Like