Support Custom GitHub Action use of GITHUB_ENV

[rlespinasse]

Is your feature request related to a problem? Please describe.
Some GitHub Actions use GITHUB_ENV to set up custom environment variables.
When used inside a workflow, use ${{ env.CUSTOM_VARIABLE }} is flagged as Context access might be invalid.

Describe the solution you'd like
Enable the custom GitHub Actions developer to define statically or dynamically the generated environment variables (like for the action output) and use it in this plugin to remove false-positive.

Additional context

This workflow is flagged with the issue

name: "Context access might be invalid"
on: push
jobs:
  context-access-might-be-invalid:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup environment variables
        uses: rlespinasse/github-slug-action@v4

      - name: Print custom environment variables
        run: echo ${{ env.GITHUB_REF_SLUG }}

And produces

[kristof-mattei]

Another example:

# yaml-language-server: $schema=https://json.schemastore.org/github-workflow.json
name: Something

on:
  pull_request:
    branches:
      - main

jobs:
  job1:
    name: Job1
    runs-on: ubuntu-latest
    outputs:
      code: ${{ steps.filter.outputs.code }}

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Check if we actually made changes
        uses: dorny/paths-filter@v2
        id: filter
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          filters: .github/file-filters.yml

      - shell: bash
        run: |
          echo ${{ fromJSON(env.SOME_ENV) }}

[rdhar]

Same here; additions to GITHUB_ENV return "Context access might be invalid: REF" warning.
This is true for both expressions (i.e., if: env.REF) as well as environment variable interpolation (i.e., ${{ env.REF }}).

Here's a workflow snippet with the same warning on every env.REF line, despite these environment variables being initialised in the previous step.

steps:
  - name: Add environment variable
    run: echo REF=${string/--*/} >> $GITHUB_ENV

  - name: Reference environment variable
    if: env.REF != 'default' # Context access might be invalid: REF
    uses: actions/github-script@v6
    with:
      script: return "${{ env.REF }}" # Context access might be invalid: REF

Thank you.

[briantist]

I understand this warning in that there is probably no way for the extension to determine that the var will exist at runtime, so it will never be able to definitively know when to warn or not.

So I think what we need is a way to tell the extension not to warn on certain vars, perhaps even scoped.

Probably something comment based like other linters use., maybe a noqa type of thing.

name: "Context access might be invalid"
on: push
jobs:
  context-access-might-be-invalid:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup environment variables
        uses: rlespinasse/github-slug-action@v4

      # noqa: runtime-reference GITHUB_REF_SLUG
      - name: Print custom environment variables
        run: echo ${{ env.GITHUB_REF_SLUG }}

Scoping would be neat, like somehow applying the noqa and then disabling it, so that you can mark the area where it should not apply instead of having it never validate that variable again in the whole workflow.

---

Workaround

This can be worked around by explicitly adding the variable to an env block anywhere before the reference in the workflow:

name: "Context access might be invalid"
on: push
env:
  GITHUB_REF_SLUG: ""

jobs:
  context-access-might-be-invalid:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup environment variables
        uses: rlespinasse/github-slug-action@v4

      - name: Print custom environment variables
        run: echo ${{ env.GITHUB_REF_SLUG }}

This is not a great workaround imo, because it masks the real issue, and means littering the workflow with useless references. Worse, it makes it more difficult to understand the workflow.

---

There are also some errors with the variable flagging (it misses some!) which I'll raise in another issue.

[tylerclark]

Fixed in next release: #61 (comment)

[felipesu19]

Considering its supposedly to be fixed , I'm closing!

[brianjmurrell]

Fixed in next release: #61 (comment)

#61 is an issue, not a PR so it can it fix anything itself. Perhaps what you mean is that actions/languageservices#15 fixes #61, but that doesn't seem entirely relevant here. Short-circuit evaluation is not even mentioned in this issue (but is mentioned in #61).

So does #61 (actually actions/languageservices#15) really fix all of the problems described in this issue? actions/languageservices#15 only mentions the problem with short-circuit operators (which is not even described in this issue, but is described in #61)?

[felipesu19]

Fixed in next release: #61 (comment)

#61 is an issue, not a PR so it can it fix anything itself. Perhaps what you mean is that actions/languageservices#15 fixes #61, but that doesn't seem entirely relevant here. Short-circuit evaluation is not even mentioned in this issue (but is mentioned in #61).

So does #61 (actually actions/languageservices#15) really fix all of the problems described in this issue? actions/languageservices#15 only mentions the problem with short-circuit operators (which is not even described in this issue, but is described in #61)?

You are correct and my closing of this was too hasty. Re-opening and re-evaluating. Sorry about that.

[carry0987]

Any updates for this issue ?

[Aetherinox]

Is this a confirmed bug others are getting? I loaded up visual studio code today to work on workflows, and I have this error everywhere, yet it's pulling info fine on Github.

[jakoch]

This is an upstream issue of the LSP, right? actions/languageservices#60