Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suppress vars context validation in an environment set via an expression. #96

Open
RDavis3000 opened this issue Apr 7, 2023 · 17 comments
Labels
enhancement New feature or request

Comments

@RDavis3000
Copy link

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//issues/67][https://github.com//issues/47]

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

Screenshot 2023-04-07 110338

@RDavis3000 RDavis3000 added the enhancement New feature or request label Apr 7, 2023
@elbrenn
Copy link
Collaborator

elbrenn commented Apr 7, 2023

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
Copy link

tofran commented Apr 10, 2023

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
Copy link

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.

@lrotschy lrotschy moved this from Backlog 🗒 to To do 📝 in GitHub Actions VS Code Extension Apr 10, 2023
@lrotschy lrotschy moved this from To do 📝 to Backlog 🗒 in GitHub Actions VS Code Extension Apr 10, 2023
@max-sixty
Copy link

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

image

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
Copy link
Collaborator

elbrenn commented Apr 19, 2023

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

@elbrenn
Copy link
Collaborator

elbrenn commented Apr 19, 2023

@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 #41 or #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 #123

@elbrenn
Copy link
Collaborator

elbrenn commented Apr 19, 2023

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.

@elbrenn elbrenn changed the title Context access might be invalid Supress vars context validation when not logged in Apr 19, 2023
@max-sixty
Copy link

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

My issue was a case of #121. All fixed now!

@RDavis3000
Copy link
Author

RDavis3000 commented Apr 24, 2023

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.

image

@elbrenn
Copy link
Collaborator

elbrenn commented Apr 25, 2023

@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
Copy link
Author

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

image

@elbrenn
Copy link
Collaborator

elbrenn commented May 1, 2023

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

@vincent-hoodoo
Copy link

vincent-hoodoo commented May 4, 2023

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 #105

@RDavis3000
Copy link
Author

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 felipesu19 changed the title Supress vars context validation when not logged in Suppress vars context validation in an environment set via an expression. May 16, 2023
@felipesu19
Copy link
Collaborator

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

@felipesu19 felipesu19 moved this from Backlog 🗒 to Triaged 📝 in GitHub Actions VS Code Extension May 16, 2023
@johnrom
Copy link

johnrom commented Nov 30, 2023

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
Copy link

alles60 commented Mar 15, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Triaged 📝
Development

No branches or pull requests

9 participants