Pass Configuration Variables to workflows triggered by a pull request from a fork

[galargh]

Select Topic Area

Product Feedback

Body

The new Configuration Variables feature is great! I'm baffled about their visibility scope, though.

Variables are not passed to workflows that are triggered by a pull request from a fork. Learn more about variables.

They could/should be passed to workflows triggered by a pull request from a fork.

Why?

• they are non-sensitive
• they are not obfuscated in GitHub Actions which makes them visible to the public already anyway

[tbouffard]

Hi, I face the same problem today.
Dependabot doesn't have access to Configuration as well, see #44088. Everything happens as if the restrictions for the Configuration Variables were the same as for the Secrets.. However, as mentioned in the description of this "Product Feedback", they are non-sensitive.

In my case, following the examples provided by the official documentation (https://docs.github.com/en/actions/learn-github-actions/variables#using-the-vars-context-to-access-configuration-variable-values), we use a Configuration Variable to declare the Runner used by the workflow. Not having access to the related runner variable always generates an error for PR created from fork or by Dependabot.
This make the usage of Configuration Variables useless.

Workflow definition: https://github.com/process-analytics/bpmn-visualization-js/blob/49315fa7136776a29053b6724f867329a919a5b7/.github/workflows/dependency-review-pr.yml#L12-L15

jobs:
  dependency-review:
    runs-on: ${{ vars.RUNNER_UBUNTU }}

Error when evaluating 'runs-on' for job 'dependency-review'. .github/workflows/dependency-review-pr.yml (Line: 14, Col: 14): Unexpected type of value '', expected type: OneOf.

[tauhid621]

The pull_request_target event can be used for scenarios where variables need to be available in a forked PR. This event runs in the context of the base of the pull request, rather than in the context of the merge commit, as the pull_request event does.

One of the reason to not allow variables available in forked PRs pull_request event was because of org variables being available in the workflow run. Workflow logs do show up the variables in plain text, but only the variables which are used in the workflow. Allowing a user to view all variables (Eg: using toJson(vars)) did not seem correct as the variables cannot be accessed with read permissions on the repo.

We are still exploring this area and taking feedback on the behaviour.

[ADTC]

Can the pull_request_target event allow the workflow run to access secrets as well (in the forked PR)?

[ADTC]

Also, would it be possible to use workflow_run to trigger a second workflow which has access to secrets and variables? Perhaps a workflow for pull_request can just complete immediately and trigger another workflow for workflow_run: completed event.

[ADTC]

It looks like pull_request_target should not be used to build or run code from the pull request because of security flaw. Since it runs in the context of PR base, it doesn't contain the changes anyway, which makes it useless for building.

[djbrown]

I fully support the restriction on Secrets. But please make Variables available to public Pull Request Workflows!! 🙏🏾
Variables do not contain sensitive data by definition, and thus should be publicly accessible from anywhere or any Level.
The Argument regarding Organization Variables doesn't really make sense to me, since they actually should be visible.

[djbrown]

*accessible for all scopes that already have read permission to the project 😉
@tauhid621 did you come to a new view or are there any other reasons to justify the current behaviour?
I really hope we can improve the current situation for the sake of Open Source Collaboration via GitHub Pull Requests ❤

[danepowell]

At the very least, the Variables documentation needs to be updated to mention that variables are not available to pull requests. I spent an hour reviewing docs and debugging why variables were not appearing in my PR actions only to find an obscure reference in this discussion.

[pbrezina]

This took me lots of time to figure out that the variables are not available for pull request scope. And +1 to the opinion that it makes this feature useless.

[ThiefMaster]

FFS, please fix this. What's even the point of variables instead of secrets when they are not accessible in PR runs. Or just give us a goddamn setting whether a variable should be accessible or not...

[ross]

I was recently excited to think of using org-level variables to define the versions of Python all of octoDNS's CI jobs should run against so that we can avoid ~30 PRs ever time active versions change. I went through and implemented a setup that does exactly what I wanted

octodns/octodns#1081 (comment)

and it worked perfectly for my PRs, but as soon as I went to work on a 3rd party PR it failed. i'd assumed that "variables" would be available to the forks since they're not "secrets" or at all sensitive, otherwise what's the purpose of having a separate category. I definitely do not want the PRs to have a RW github token, so pull_request_target doesn't make sense on top of it having the target's code and not the PRs.

Are there any updates/plans here. Not looking forward to unwind all 30 PRs assuming there's no way to get the value to PRs from forks.

[ThiefMaster]

With that many repos I'd seriously consider crating a repo containing the Python versions and loading them dynamically in all the other CI jobs. Not as nice as a variable, but better than having to update 30 repos...

[ross]

Before I came up with the variables option I thought about having a prerequisite job that fetched a file with yaml/json in it that turns that into an output that the main job uses as an input (in the matrix.)

Could feed that a github raw link for main like https://raw.githubusercontent.com/octodns/octodns/main/requirements.txt. It'd work, is a bit lower weight than fetching a whole repo, but is pretty Rube Goldberg compared to the "right" solution of variables just being available.

[ross]

My work-arounds octodns/octodns#1084, octodns/octodns-azure#73 (this is just an example, there's ~30 more of these, and octodns/terraformed#24.

I lose my nice one-PR does everything setup since we now have to PR octodns/octodns, merge that and then re-plan & apply terraform to get the updated data, but until variables are no longer treated as secrets I see now way around it.

It also takes longer for CI to run since there has to be an initial job to fetch the config so that it can be used as the matrix/input for the next job.

[gtjoseph]

This issue has been frustrating me for months. 95% of my workflow runs are triggered by pull requests from forked repos and I have no way to get CI control info without having a file in the repo, which isn't safe, or making a REST call to retrieve a file from some other location, which isn't convenient. I don't understand why there's no facility to do this. If you've got something secret, it should be in secrets.

[jcs090218]

I have this exact same issue. :(

[justinfx]

Just spent an hour trying to figure this out as well. I have a CI pipeline that works fine when I do PRs from the same repo. But then someone submits a PR from their fork and neither the environment variables nor the repository variables expand properly and it breaks. I don't understand how to support other people submitting PRs from their forks without this feature.

[redcode]

If forks cannot inherit repository variables from the upstream repository, then repository variables are broken by design. Why do they exist?

Please fix this. Repository variables would be great if they worked the way everyone expects them to work, not the way someone who implemented them thought they should work.

[ichorid]

This is ridiculous and makes us reconsider using GitHub for alternatives, since the forks system is the reason we choose GitHub originally

[Kagameow]

Unfortunately, the current behavior of configuration variables limits the ability to perform proper checks when creating a pull request from a fork. This is certainly not an ideal situation if we consider any workflow that uses forks.

[soumyamahunt]

Is having variables as part of environment and using specific environments for jobs a good workaround for this?

[bclark8923]

Any movement on this?

[braxton-mills]

Good lord I just wasted four hours because the docs still don't mention that the Context access for "vars" isn't scoped to PRs.

I don't understand why this restriction was made; at the very least, please update the docs.

[carlosmiei]

• 1 who lost hours because of this... makes no sense at all

[gustavovalverde]

At least allow a member of the repository to trigger a workflow in a PR coming from a fork, so that it can inherit those permissions. Right now, not being able to read the variables at all is a blocking issue with no workaround, since pull_request_target is not a workaround for this.