"Context access might be invalid" warning thrown for repository variables and secrets

[afefer]

Describe the bug
After upgrading to 0.25.8, a "Context access might be invalid" warning is thrown for all repository variables and secrets in the workflow file. Refreshing the secrets/vars in the extension has no effect.

Expected behavior
Secrets/vars should not throw a "Context access might be invalid" warning.

Screenshots

Extension Version
v0.25.8

Additional context
Add any other context about the problem here.

[aschen-builder]

Also seeing this issue still with the latest release.

Previous issues #47 #61 and #67 stated the issue would be fixed with the next release, but issue continues to persist into release v0.25.8 and the change log seems to make no mention of a fix being deployed.

[moshest]

Any update on this?

[acharyasaagar]

I still see this as well; the extension version is v0.25.8

[evertonspader-tomtom]

Seeing the same here constantly with v0.25.8

[avh03]

Just wanted to confirm that the issue continues to persist in 0.25.8 (and it's feeling really annoying)

[anthony9187]

also seeing this constantly in v0.25.8 with env variables, but not secrets

[mickael-h]

Same here. A bit annoying indeed 👍

[Bohemus307]

Still persists kind of embarrassing for GH

[enriquepevida]

ah, i see this is an actual issue. i was going mad with this. Let´s hope it´s fixed soon.

[felipesu19]

Yep, its a bug. Moved to triage. No ETA on a fix, if someone makes a PR to fix, I'm happy to review it.

[PrimeTimeTran]

I uninstalled, reinstalled and restarted VSCode and then the warnings went away. v0.25.8

[techguydave]

I was receiving this error after installing the extension. Simply running the "Developer: Reload Window" command fixed it for me without needing to reinstall. So far it hasn't seemed to return yet, at least for repo secrets.

[japo32]

I was receiving this error after installing the extension. Simply running the "Developer: Reload Window" command fixed it for me without needing to reinstall. So far it hasn't seemed to return yet, at least for repo secrets.

I tried this but it came back :(

[adambirds]

Okay, at least in my instance, the issue seems to be because I have a setup like this:

organization/repo - Main repository. Secrets/vars are done on this.

myuser/repo - Fork which I do my work on before creating a merge to push to upstream/main. Therefore in actions, its thinks the vars/secrets don't exist because they existing the main repo not my fork. There should at least be a way of ignoring this specific error if this is the case.

[larouxn]

👋 Reporting in, still happening on v0.26.1.

There should at least be a way of ignoring this specific error if this is the case.

Agreed, there should at least be a # github-actions-extension ignore comment one can use.

[gregalia]

I get this warning for any environment variable exported in a previous step via echo "foo=bar" >>$GITHUB_ENV

v0.26.1

[JoelYoung01]

I uninstalled, reinstalled and restarted VSCode and then the warnings went away. v0.25.8

This worked for me.

[BertelBB]

This seems to only happen when environment property is dynamic.

[marano]

I get this error for all of my secrets, am I missing something?

[budokans]

Expected behavior
Secrets/vars should not throw a "Context access might be invalid" warning.

I actually like this warning. Because our YAML file has no access to production environment variables when we're editing it, it's a nice reminder to double-check our variable names.

[BertelBB]

Expected behavior
Secrets/vars should not throw a "Context access might be invalid" warning.

I actually like this warning. Because our YAML file has no access to production environment variables when we're editing it, it's a nice reminder to double-check our variable names.

That's one way of looking at it. I would say a more realistic view is that it will condition you to ignore the warnings which causes the opposite effect of what you described.

[drewagentsync]

I'm seeing this same behavior when pulling an output from a previous step through needs "Context access might be invalid". Is this being triggered by the value not being available to read because the previous step has not run? Just wondering as you'd think it could see the output it'd be pulling the value from is in the previous needed step.

[qortex]

I had this error on secrets. Turns out I wasn't properly signed in on github inside Vscode. Signing in and reloading fixed the issue.

[lukesneeringer]

I had this error on secrets. Turns out I wasn't properly signed in on github inside Vscode. Signing in and reloading fixed the issue.

How does one "sign in to GitHub inside VS Code"?

And I'd argue this is a bug regardless; if you're not signed in, then it should just assume all variables are fine, not spam you with spurious warnings.

[hsyhhssyy]

However, this will cause VSCode to color this folder yellow, override source control's color. I can't tell if any project is committed or not as all my project folders are alway marked yellow. I might forget to commit changes for that reason.

[davearel]

How does one "sign in to GitHub inside VS Code"?

Open the "github actions" extension side-panel and click "Sign in with Github".

Authenticating this extension with Github worked for me.

And I'd argue this is a bug regardless; if you're not signed in, then it should just assume all variables are fine, not spam you with spurious warnings.

I agree this is still a bug, but Instead of assuming all variables are correct (which could easily be mistaken for being a valid secret) it should indicate that secrets (and potentially other checks) cannot be verified until authenticated. This extension requires authentication for a lot of features.

[bhperry]

Would be great if this could work without requiring github login. I would be completely fine with it assuming the required secrets exist when it doesn't know otherwise.

[maksims-terjohins]

I have found a solution that works at least for me.
SECRET squiggles and ENVIRONMENT squiggles have had different causes (in my case at least).

1. In order to get rid of SECRET warning squiggles I had to properly login and then reload the screen (that was resolved easy, thanks to comments before). Secrets are defined in same repo, where this workflow .yaml file is located.
2. To remove warning squiggles from ENVIRONMENT variables, I had to add env: statement with definition of each Environment variable I was about to use in particular Step. Example:

This Step definition causes warning squiggles to appear under env.TAG_VERSION (BAD):

- name: Build x86 Image
        uses: docker/build-push-action@v3
        with:
          context: .
          file: DockerfileAMD
          platforms: linux/amd64
          tags: username/image_name:${{ env.TAG_VERSION }} 

How this warning looks like in IDE:

Now, this Step definition REMOVES warning squiggles under env.TAG_VERSION (GOOD):

- name: Build x86 Image
        uses: docker/build-push-action@v3
        env:
          TAG_VERSION: ${{ env.TAG_VERSION }} 
        with:
          context: .
          file: DockerfileAMD
          platforms: linux/amd64
          tags: username/image_name:${{ env.TAG_VERSION }} 

How this looks like now:

How my Environment variables are defined (in previous prior to Build x86 Image Step ):

echo "TAG_VERSION=12345" >> $GITHUB_ENV

There is no other place in whole repository where I would somehow mention to use this Environment variable; the mentioned definitions were enough for me.

Although my workflow was working well even without adding this env: property, adding it have resolved my issue with warning squiggles.

[thoughtfuldata]

@davecaplinger I am having a related issue with steps.action-id.outputs.* where I get "Context access might be invalid" if the * is being dynamically set by the github action (i.e action-id) based on user input.

[robloxiandemo]

If you're still experiencing this issue, try using a fromJSON(toJSON(env | vars | secrets).[...]

An example of how it'd look:

${{ fromJSON(toJSON(secrets)).GITHUB_TOKEN }}

This method's not the best of solutions, though it works if your local repository is unable to fetch / verify whether the specified environment variable or secret is really present.

I still wouldn't rely on this, rather go for this method of trying to resolve it, as it worked for my latest repository.

[SyedSibtainRazvi]

If you're facing the "Context access might be invalid" warning for repository variables and secrets. The reason is our YAML file does not have access to production environment variables when we're adding it. The warning is simple and here is what worked for me.

1. Add the required secrets in your GitHub repository settings.
2. After adding secrets, perform a developer reload in VS Code.

This should make the warning disappear.

[davecaplinger]

@maksims-terjohins - thanks, this solved the problem for me too.

[jivea]

Hello everyone,

After signin in the Github Actions extensions, I alos had to tick the "Use-enterprise" option in the Github Action extension settings.
Repo belongs to an organization account.
Hope this will help someone.

[CanePlayz]

For me, it seems to be working out of the box now, without having to apply any of the proposed fixes from here

[Zain-ul-din]

You need to understand how this works. it fetches variables name from your GitHub account if you have created a variable there it will not give any warning.

- Context access might be invalid: PHPSESSID
- Contains the names and values of secrets that are available to a workflow run. For more information

Giving a Warning due to PHPSESSID is not in my Github secrets.

If the warning persists even after adding the variable in GitHub, consider reloading VS Code.

[franccesco]

Are you using MacOS? I had to restart VS Code with ⌘ + Q, and it went away after checking I did have the secrets correctly set in my repository settings.

[Zain-ul-din]

@franccesco No, I'm using windows.

[promid]

How do I surpress such warnings when reading secret values with env as the key?

[SyedSibtainRazvi]

@promid After adding the env, can you restart the VS code. (Developer:Reload Window)

[promid]

@promid After adding the env, can you restart the VS code. (Developer:Reload Window)

Thanks for the reply, @SyedSibtainRazvi. I forgot to say that the envs are set by echo aaa=bbb >> $GITHUB_ENV.

[ecker-deshaw]

Is there any way to disable this warning when using a dynamic environment?

[SaraGMatos]

Relogging into Actions and reloading window fixed the warning for me too!

[ezfe]

Joining the club asking about this - I've got dynamic environment variables and VS Code extension won't shut up about me referencing them

[fnfup]

I can also confirm this happens when you specify the jobs context environment property dynamically. It's not able to properly track that a variable exists. This is specific to "variables" my "secrets" seem to be tracked correctly.

[klausbadelt]

You need to understand how this works. it fetches variables name from your GitHub account if you have created a variable there it will not give any warning.

We do have all variables "in our GitHub account", still getting VS Code warnings.

[klausbadelt]

@jivea

After signin in the Github Actions extensions, I alos had to tick the "Use-enterprise" option in the Github Action extension settings. Repo belongs to an organization account. Hope this will help someone.

That just logs me out, without being able to log back in ("Sign in" button no longer works). I guess that's why you don't see the warnings - you're logged out. I suspect that's because now the Github-enterprise Uri is missing. (We do run a GitHub organization, but not GitHub enterprise).

[JoseEduardoCarrera]

This is my experience:

After opened .yml file for the first time, VS Code Askme to install the Github Action Extension, i get access to my secrets and variables in the lateral panel but in config i get the same warn message, but i restarted the VS Code Programm and the warn message dissapeared

[Hassen-Ahmed]

This worked for me after carefully adding GitHub Secrets, pushing/pulling my repo, and then pressing Ctrl + Shift + P and selecting "Developer: Reload Window.

[ssbarnea]

I want to use the language server for GHA without having the sidebar enabled but apparently that is required in order to access the secrets.

I would rather have an option to disable messages like this as they are distracting and incorrect. They should appear only when the extension can access secrets and fails to find them, not when it does not have access to them.

[sunski411]

If you installed the GitHub Actions extension, all you have to do is perform a Developer reload in VS code 'Developer: Reload Window' and the error should go away.

[scarecrow-11]

Restarting the VSCode Window doesn't seem to be working here.

[8192K]

In a devcontainer, the only way for me was to disable the extension, click reload and then enable it again.

[grantjoy]

After signin in the Github Actions extensions, I also had to tick the "Use-enterprise" option in the Github Action extension settings. Repo belongs to an organization account. Hope this will help someone.

This did it for me. Thank you @jivea!