Add support for Github Actions Variables

[lktslionel]

Hello,

GitHub releases GitHub Actions Variables. It will be great to be able the use vars.VAR_NAME with our workflow document.

See: https://docs.github.com/en/rest/actions/variables?apiVersion=2022-11-28

Thanks
Regards

[lktslionel]

I'm open to contributing but I need guidance on how to get started and which part of the code is handling that part.
I think it will be similar to how env.EEEE and secrets.XXX are being handled but apart from that, I am completely blind 😄 .

[KnisterPeter]

Hi @lktslionel,
first of all I think there need to be an idea how to add this to act. Currently there is no access to GitHub APIs and I do think it shouldn't be there. Secrets and Env-Vars are set via the command line and I could think of that for vars as well.

A starting point would be to add them to the expression parser (stating here: https://github.com/nektos/act/blob/master/pkg/exprparser/interpreter.go#L150)
And then work up all the way to the command line arguments.

[grantcarthew]

I tried to pass "vars" in the environment variable command line option:

act --env 'vars.FOO=BAR'

This didn't work.
This is a show-stopper for me. Well, I can't have an action that works with GitHub and act.

Sorry, I'm not a Go dev yet and am time-limited (aren't we all?).

[mcascone]

+1 agree, not supporting variables - as opposed to environment variables - is a big miss. I don't even have environment variables in my personal repo. 💯 agree with following the same patters as .env and .secrets: support .vars with the same mechanisms: default to .vars, override with --vars-file.

Thanks! :)

[haktan-suren]

+1

[mwierzchowski]

IMHO, all the contexts (like env, vars, secrets) should be handled the same way by act. No need for integration with the GitHub API - probably that would be completely undesired since may lead to unexpected sideeffects. As additional thing to consider, all types contexts could be defined in one file (with separate sections). This could simplify managing all the values at once and simplify setup (e.g. 1 entry in the .gitignore). In the scenario where all the contexts are defined in one file, we could consider format a little more human readable. YAML or TOML maybe?

[kferrone]

This needs to be very high priority. This is not ready for use without it.

[adamhalesworth]

It would be great to be able to supply vars to act, e.g. to provide a RUN_OFFSET to maintain build continuity (which is my use case). Using secrets is workable, but it makes the process cumbersome since the value is hidden in the UI.

As @mwierzchowski suggested, YAML or TOML is very readable and could simplify context configuration, but even having this implemented in the same format as .env would be fantastic.

[basos9]

This is needed for sure

[mcascone]

@KnisterPeter, I opened #1802 to implement this, but i'm really working blind here. I just copied the pattern used for the Env var, and created a Vars flow. I'm happy to follow this through but i'll need to some guidance on where to go next.

[KnisterPeter]

@mcascone You probably need to go through all act code here from the cli options parsing to all call sides of the expression parser. This is not the smallest change and up to now you only touched the surface (the parser). I would suggest to make yourself familiar with the whole codebase.

[wildsheepz]

@KnisterPeter, I made the changes needed to add a --var-file, tested using a workflow to verify that secrets is still masked and ${{ vars.Example }} is working.

[askb]

When is this fix going to be out! Having the same issue with out tests and workflow. It's going to be a pain to rewrite all the workflows to change the all the var to env.

[Gerrit Verify/prepare] Unable to interpolate expression 'format('{0}', vars.GERRIT_SSH_USER)': Unavailable context: vars
[Gerrit Verify/prepare] Unable to interpolate expression 'format('{0}', vars.GERRIT_KNOWN_HOSTS)': Unavailable context: vars
[Gerrit Verify/prepare] Unable to interpolate expression 'format('{0}', vars.GERRIT_SERVER)': Unavailable context: vars

[wildsheepz]

Well, I have a full time job and writing the unit tests to satisfy the coverage requirements is going to take time. You could just compile it from my fork and use that if you need it urgently.

[grantcarthew]

Hi Kuan @wildsheepz,
Just wanted to say thanks mate. It looks like you're the only one stepping up for this and there will be many people interested. Your work is appreciated.

[wildsheepz]

#1833 has been merged into master.

[askb]

Thanks for fixing this Kuan @wildsheepz

[duzenko]

a@a-virtual-machine:/mnt/hgfs/Remote/cashare-react-ui$ ./bin/act --var FTP_DIR_STAGING=qwe
Error: unknown flag: --var

[wildsheepz]

a@a-virtual-machine:/mnt/hgfs/Remote/cashare-react-ui$ ./bin/act --var FTP_DIR_STAGING=qwe
Error: unknown flag: --var

It's merged into main, but the version has not bumped yet. If you need it now, you will need to compile master on your own.

[duzenko]

Sorry, whose job is it to "bump the version"?

[haktan-suren]

For those who don't know how to build from master

brew unlink act  
brew install act --HEAD

[askb]

For those who don't know how to build from master

brew unlink act  
brew install act --HEAD

Is there an equivalent to build / install the binary using the HEAD on other platforms?
ex on linux we use curl -s https://raw.githubusercontent.com/nektos/act/master/install.sh | bash

[dragonprevost]

Thank you @wildsheepz 🙏

[L-Sypniewski]

I don't want to open an issue since I'm not sure if the problem is on my side, but the variables don't work for me (secrets are correctly substituted). I've tried both with .env file and passing a value as a commandline parameter:

act -j  deploy-chagnes-to-dev-db --secret-file ./.act/.secrets -var SUPABASE_DEV_PROJECT_ID=<ID_VALUE> 

Replacing ${{ vars.SUPABASE_DEV_PROJECT_ID }} with the actual value fixes the problem.

According to the docs from a linked PR it should work: To run act with repository variables that are acessible inside the workflow via ${{ vars.VARIABLE }},

A piece of code from my Github actions:

  deploy-chagnes-to-dev-db:
    defaults:
      run:
        working-directory: ./Frontend/
    name: Lint Supabase and apply migrations to dev instance
    runs-on: ubuntu-24.04
    env:
      SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_DEV_ACCESS_TOKEN }}
      SUPABASE_DB_PASSWORD: ${{ secrets.SUPABASE_DEV_DB_PASSWORD }}
      SUPABASE_PROJECT_ID: ${{ vars.SUPABASE_DEV_PROJECT_ID }}
    timeout-minutes: 10
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Install Supabase CLI
        uses: supabase/setup-cli@v1
      - name: Create fake .env file for Supabase CLI
        run: |
          echo 'GITHUB_CLIENT_ID="SOMEID"' > .env
          echo 'GITHUB_SECRET="SOMESECRET"' >> .env
          echo 'SENDGRID_API_KEY="SOMEKEY"' >> .env
          echo 'OPENAI_API_KEY="SOMEKEY"' >> .env
      # - name: Start supabase DB
        # run: supabase db start
      # - name: Lint Supabase
        # run: supabase db lint
      - name: Apply migrations to dev instance
        run: |
            supabase link --project-ref "$SUPABASE_PROJECT_ID"
            supabase db reset --linked