"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.

[SoaAlex]

How should this work for callable workflows? The plugin obviously can't know if necessary secrets/vars are in place in the repository which invokes my callable workflow.

There should definitely be a enable/disable for this feature.

Same, I have environment variables set in another callable workflow / action dynamically and of course it's no able to see it. I just would like to disable this warning, is this possible ?

[CalebBarnes]

This was fixed for me by opening the GitHub actions side panel, making sure its logged in, refreshing, then opening the Secrets dropdown. Then after that, I ran the vscode command > Developer: Reload Window.

Now it is working fine.

[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.

[matschaffer-roblox]

+1 to @BertelBB and @larouxn for a way to ignore this warning for certain repos or secrets.

For context, we have a setup where secrets are managed by a separate team. Most users aren't able to access that part of the repo settings so there's no way to validate presence.

Being able to supply a list of presumed-available secrets via an in-repo settings file would probably do the trick in our case.

Update: I can't see the repo settings, but looks like after updating access and reloading the window the errors did go away per @CalebBarnes's comment https://github.com/github/vscode-github-actions/issues/222#issuecomment-1877836952

[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.

[dongbeiqing91]

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)

[dongbeiqing91]

@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!

[brimmann]

Restarting worked for me.

[OkkarMin]

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.

This worked for me!

[grantjoy]

Use-enterprise worked for a while until it stopped working. Downgrading to 0.25.7 got it working again.

Something changed between 0.25.7 and 0.25.8 that broke the auth for the extension and that bug persists today through all version after 0.25.7.

The error I see when moving from 0.25.7 and 0.25.8 (after authing in 0.25.7) is: Error running command github-actions.explorer.current-branch.refresh: command 'github-actions.explorer.current-branch.refresh' not found. This is likely caused by the extension that contributes github-actions.explorer.current-branch.refresh.

[boonyarit-iamsaard]

Here is my workaround, I switched from SSH to HTTPS and the warning disappeared. I hope this helps.

[ssbarnea]

While I can fully understand why this feature was implemented there is a significant number of power-users of GHA which might use advances workflows, where the static analysis fails.

I have another job that is producing the entire matrix for for running the matrix tests jobs, and I am using its output. Here is how is used:

    outputs:
      matrix: ${{ steps.generate_matrix.outputs.matrix }} # noqa: unknown-context
      # triggers ^ "Context access might be invalid: matrix"

The only way to avoid is is to have some kind of magic noqa comments to silence it, like the comment that I added in the snippet.

Looking at https://github.com/github/vscode-github-actions/graphs/contributors I realise that this extension is not really under any kinda of active maintenance. In fact the last change that worth being mentioned in the release notes was in may 2023 :)

Still, I hope that @thyeggman might find some time to help here, even it would be with a comment that just suggests how this could be addressed (code reference, prefered way to deal with it in code).

[grantjoy]

@boonyarit-iamsaard thanks for the suggestion but I run into the same problem using HTTPS as I do for SSH auth.

@ssbarnea I don't understand why they are still upgrading it at this point, as recently as 2 months ago. They broke it in 0.25.8 and just keep releasing broken versions.

[Zoltag]

Environment: WSL2 Ubuntu Github Actions version: v0.26.5

I am using a mixed environment - Github Enterprise for our codebase and Github for external resources. When I select Use-Enterprise, external resources are shown to be unavailable and when I deselect this option, internal resources are unavailable

In the first screenshot, it shows invalid token warnings - A simple developer reload window + sign back into Github is enough to resolve these, but the Sonar action from github.com cannot be found

In the second screenshot, the secrets seem to be detected correctly (despite being in the Enterprise repo), but the action located in the enterprise git cannot be found (even though I am authenticated to both enterprise and public githubs, action resolution appears to be linked to the Use-Enterprise toggle, while secrets resolution seems to always work - albeit with some bugs)

[SantiiRepair]

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.

Not working

[rohityadav-sas]

@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).

This worked for me

[gekh]

I have two actions for test and production branches. What helped me:

• Git: Checkout to... test
• Developer: Reload window
• Git: Checkout to... produciton
• Developer: Reload window

[tensor-works]

Still an issue almost 2 year later what is the github team doing