Suppress `vars` context validation in an environment set via an expression.

[RDavis3000]

Problem: I am using a lot of repository environment variables, access via the vars context. The plugin is raising "Context access might be invalid:" warnings on every line which makes it difficult to spot actual issues and is making me sad.

Proposed solution:

I think that this functionality isn't relevant for vars/secrets contexts because there is no way for them to be discernible by the plugin.

It would be great to be able to configure the plugin to ignore these warnings in some circumstances (such as by a string pattern or by check boxes for various contexts. Or at least to be able to turn it off globally.

Additional context Related to [https://github.com/github/vscode-github-actions/issues/67][https://github.com/github/vscode-github-actions/issues/47]

Screenshot of my minimap to show you what I'm dealing with, all the yellow lines are this warning!

[elbrenn]

I think that this functionality isn't relevant for vars/secrets contexts because there is no way for them to be discernible by the plugin.

The extension hits GitHub secret/ variable APIs to determine which secrets and variables are available to the workflow. Have you signed in to GitHub in the extension? If so can you try reloading VS Code

[tofran]

Have you signed in to GitHub in the extension

Yes this is the problem. It would make sense for the syntax checking to work without being signed in or having permission on the target repositories. It makes sense that some features require you to be logged-in but the linting is quite useful, even if completely offline. GitHub should consider users that do not have their account signed-in.

[doubleforte]

I'm signed in, but we have a few env vars that are set by previous steps -- not in the env: setting or in GitHub's environment, so the plugin doesn't know about them and complains.

Would be nice to be able to either turn off this error globally, or suppress it on a line-by-line or full-file case. Similar to Typescript's // @ts-ignore or similar.

[max-sixty]

I'm getting these throughout my project — five of them in this file, for example: https://github.com/prql/prql/blob/d09c3acad05b35b3f2565c51e045b689acea10b4/.github/workflows/release.yaml#L103

The secrets do exist — here's a screenshot from https://github.com/PRQL/prql/settings/secrets/actions

I'm signed in on the GitHub Pull Requests extension. Should I be signed in on this extension too? How? (Searching for "Sign in" in the command palette doesn't find any additional hits).

Thanks!

[elbrenn]

@max-sixty if you select the Actions Extension tab, do you see a prompt to sign in?

[elbrenn]

@doubleforte

I'm signed in, but we have a few env vars that are set by previous steps -- not in the env: setting or in GitHub's environment, so the plugin doesn't know about them and complains.

This sounds similar to the issues tracked in https://github.com/github/vscode-github-actions/issues/41 or https://github.com/github/vscode-github-actions/issues/47

Would be nice to be able to either turn off this error globally, or suppress it on a line-by-line or full-file case. Similar to Typescript's // @ts-ignore or similar.

Tracked in https://github.com/github/vscode-github-actions/issues/123

[elbrenn]

It sounds like the request here is "disable vars context validation when not logged in. Updating the title to reflect this more specifically. Let us know if that does not cover your scenario.

The extension already does this for other contexts, such as secrets.

[max-sixty]

@max-sixty if you select the Actions Extension tab, do you see a prompt to sign in?

My issue was a case of https://github.com/github/vscode-github-actions/issues/121. All fixed now!

[RDavis3000]

It sounds like the request here is "disable vars context validation when not logged in. Updating the title to reflect this more specifically. Let us know if that does not cover your scenario.

The extension already does this for other contexts, such as secrets.

Hi, sorry for the delay, I sometimes miss these.

I AM logged in and the extension can see the variables fine. And yet the wall of yellow persists.

So it seems unrelated to being logged in unless I am misunderstanding something.

Secrets are working fine, it's just variables which seem borked.

[elbrenn]

@RDavis3000 are those repository, environment, or org variables?

If they are environment variables, can you include the portion of your workflow file where you set the environment for the job in your screenshot

[RDavis3000]

@RDavis3000 are those repository, environment, or org variables?

If they are environment variables, can you include the portion of your workflow file where you set the environment for the job in your screenshot @elbrenn they're repository variables, set by GitHub Cli:

gh variable set -e DEV -f someFile.env

This is how the reference is setup:

[elbrenn]

Thabks for all of this context!

The -e in that command indicates that it an environment variable associated with the environment DEV.

On line 17 of your workflow, you are setting your environment (presumably to DEV or some other environment) via an expression.

We should suppress validation for variables if there is an environment set via an expression. We have https://github.com/github/vscode-github-actions/issues/41 tracking doing this for secrets

[vincent-hoodoo]

I was getting warnings when I wasn't logged in, so I logged in, restarted VSCode and it worked fine, the warnings are gone and I can see the completion for all secrets when I type secrets..

However, the warnings are still showing in the "Problems" tabs. When I click on a problem in the "Problems" tab, even though I already have that file open just above (displaying the path relative to the workspace), it opens a new tab, with the full path as file name, and this file lists the warnings..

Related to https://github.com/github/vscode-github-actions/issues/105

[RDavis3000]

Thabks for all of this context!

The -e in that command indicates that it an environment variable associated with the environment DEV.

On line 17 of your workflow, you are setting your environment (presumably to DEV or some other environment) via an expression.

We should suppress validation for variables if there is an environment set via an expression. We have #41 tracking doing this for secrets

That makes sense, hopefully it gets tweaked soon :)

[felipesu19]

I've updated the title, I'm also quoting the relevant post here so whoever picks this up knows where to start the work:

Thabks for all of this context!

The `-e` in that command indicates that it an environment variable associated with the environment `DEV`.

On line 17 of your workflow, you are setting your environment (presumably to `DEV` or some other environment) via an expression.

We should suppress validation for variables if there is an environment set via an expression. We have https://github.com/github/vscode-github-actions/issues/41 tracking doing this for secrets

[johnrom]

In addition to suppressing these warnings when an environment can't be determined, I'd like to suggest the option of a hint here. I prefer a metadata-based approach so it doesn't affect the way builds work. However, if it's easier to evaluate expressions or parse inputs during static analysis, that might work depending on the situation.

It would be great to be able to hint to bring back validation for secrets too, as it's very easy to make mistakes within nested actions.

• Add workflow_dispatch.inputs type=choice or workflow_dispatch.inputs type=environment to workflow_call.inputs and check variables against the matrix of possible options.

  on:
    workflow_call:
      inputs:
        deployment_environment:
          required: true
          type: choice # or `environment` to support all environments
          options:
            - staging
            - prod
  

• Providing a static analysis value hint comment in one of these places:

  # see https://carvel.dev/ytt/docs/v0.44.0/yaml-primer/#annotating-yaml for an example of a parser which uses annotations
  # I based this format off of that one, but any comment-based hinting would work
  # (I just searched for "yaml annotations" and it's the first relevant result)
  jobs: 
    deploy:
      runs-on: ubuntu-latest
      #@github/static value=staging
      environment: ${{ inputs.deployment_environment }} #@github/static value=staging
      #@github/static matrix=staging,prod
      environment: ${{ inputs.deployment_environment }} #@github/static matrix=staging,prod
  

• Provide workflow-level or job-level metadata about supported environments and check variables against each:

  on:
    workflow_call:
  metadata:
    supported_environments: 
      - staging
      - prod
  jobs: 
    deploy:
      runs-on: ubuntu-latest
      environment: ${{ inputs.deployment_environment }}
      supported_environments: 
        - staging
        - prod
  

• Evaluating the default of an input:

  on:
    workflow_call:
      inputs:
        deployment_environment:
          required: true
          default: staging # use staging for static checking by evaluating each input with default or null
          type: string
  

• Providing a fallback value to the environment that can be used for static checking:

  jobs: 
    deploy:
      runs-on: ubuntu-latest
      environment: ${{ inputs.deployment_environment || 'staging' }}
  

[alles60]

The problem is still present in v0.26.2. The environment of our jobs is set via a choice input:

 workflow_dispatch:
    inputs:
      destination:
        description: 'Promotion destination'
        type: choice
        required: true
        default: ap
        options:
          - ap
          - pr
[...]
 environment: ${{ github.event.inputs.destination }}

So, for every variable in an environment, I get the warning. But every variable defined at the repository level doesn't have the warning.