#69 - [GH-ISSUE #104] Unable to interpolate string - hyphenated variables - starred/act

kerem commented

2026-03-01 21:39:42 +03:00

Owner

Originally created by @mced on GitHub (Feb 25, 2020).
Original GitHub issue: https://github.com/nektos/act/issues/104

I'm facing an issue when I'm trying to reference a steps.<id>.outputs.<variable> with an id composed with -.

Run echo ${{ steps.login-ecr.outputs.registry }}
ERRO[0005] Unable to interpolate string 'echo ${{ steps.login-ecr.outputs.registry }}' - [ReferenceError: 'ecr' is not defined]

Workaround; remove all - in id names.

Originally created by @mced on GitHub (Feb 25, 2020). Original GitHub issue: https://github.com/nektos/act/issues/104 I'm facing an issue when I'm trying to reference a `steps.<id>.outputs.<variable>` with an id composed with `-`. ``` Run echo ${{ steps.login-ecr.outputs.registry }} ERRO[0005] Unable to interpolate string 'echo ${{ steps.login-ecr.outputs.registry }}' - [ReferenceError: 'ecr' is not defined] ``` _Workaround; remove all `-` in id names._

kerem

2026-03-01 21:39:42 +03:00

closed this issue
added the
kind/bug

needs-work

area/workflow

meta/workaround
labels

kerem commented

2026-03-01 21:39:43 +03:00

Author

Owner

@cplee commented on GitHub (Feb 25, 2020):

i was afraid of this :(

Implementing the expression logic in act was interesting. I noticed that if i squinted enough that the syntax looked like javascript, so i used robertkrimen/otto to process it as javascript. Unfortunately, javascript doesn't allow - in variable names, but GH expressions does.

Any ideas on how to fix?

@cplee commented on GitHub (Feb 25, 2020): i was afraid of this :( Implementing the expression logic in `act` was interesting. I noticed that if i squinted enough that the syntax looked like javascript, so i used [robertkrimen/otto](https://github.com/robertkrimen/otto) to process it as javascript. Unfortunately, javascript doesn't allow `-` in variable names, but GH expressions does. Any ideas on how to fix?

kerem commented

2026-03-01 21:39:43 +03:00

Author

Owner

@mced commented on GitHub (Feb 25, 2020):

From the blogpost I've just read [1] and the releases history, you actually used a parser released by github. Unfortunately actions/workflow-parser is dead. Can you tell me what happened ?

[1] https://github.blog/2019-02-07-an-open-source-parser-for-github-actions/

@mced commented on GitHub (Feb 25, 2020): From the blogpost I've just read [1] and the releases history, you actually used a parser released by github. Unfortunately [actions/workflow-parser](https://github.com/actions/workflow-parser) is dead. Can you tell me what happened ? [1] https://github.blog/2019-02-07-an-open-source-parser-for-github-actions/

kerem commented

2026-03-01 21:39:43 +03:00

Author

Owner

@cplee commented on GitHub (Feb 25, 2020):

The first cut of actions was completely different from the GA version. Seems like it was a rewrite to be based on Azure DevOps.

@cplee commented on GitHub (Feb 25, 2020): The first cut of actions was completely different from the GA version. Seems like it was a rewrite to be based on Azure DevOps.

kerem commented

2026-03-01 21:39:43 +03:00

Author

Owner

@mced commented on GitHub (Feb 25, 2020):

You're right, it was based on HashiCorp HCL. Now GA uses yaml syntax.
Thus I'd say to replace otto by an yaml parser, but I won't :)

@mced commented on GitHub (Feb 25, 2020): You're right, it was based on HashiCorp HCL. Now GA uses yaml syntax. Thus I'd say to replace otto by an yaml parser, but I won't :)

kerem commented

2026-03-01 21:39:43 +03:00

Author

Owner

@cplee commented on GitHub (Feb 25, 2020):

The problem here isn't the parsing of the workflow files. I am using yaml parser for those (and previously the lib for HCL from github). However, some of the values in the yaml have a custom GitHub expression: https://help.github.com/en/actions/reference/contexts-and-expression-syntax-for-github-actions

That expression is what needs an evaluator, and what I use Otto for

@cplee commented on GitHub (Feb 25, 2020): The problem here isn't the parsing of the workflow files. I am using yaml parser for those (and previously the lib for HCL from github). However, some of the values in the yaml have a custom GitHub expression: https://help.github.com/en/actions/reference/contexts-and-expression-syntax-for-github-actions That expression is what needs an evaluator, and what I use Otto for

kerem commented

2026-03-01 21:39:43 +03:00

Author

Owner

@icarcal commented on GitHub (Feb 27, 2020):

Hey guys, I'm having the same problem here :(

As @mced pointed out,for a workaround to this, you can switch all variables with - to _ for example.

The problem is when you have another action that implement output variables, for example: actions/cache

When I check for the steps.yarn_cache.outputs.cache-hit != 'true', I receive the following error:
sh ERRO[0017] Error evaluating expression 'steps.yarn_cache.outputs.cache-hit != 'true'' - ReferenceError: 'hit' is not defined

Great work in this package btw.

@icarcal commented on GitHub (Feb 27, 2020): Hey guys, I'm having the same problem here :( As @mced pointed out,for a workaround to this, you can switch all variables with `-` to `_` for example. The problem is when you have another action that implement output variables, for example: [actions/cache](https://github.com/actions/cache/blob/master/action.yml#L15) When I check for the `steps.yarn_cache.outputs.cache-hit != 'true'`, I receive the following error: `sh ERRO[0017] Error evaluating expression 'steps.yarn_cache.outputs.cache-hit != 'true'' - ReferenceError: 'hit' is not defined ` Great work in this package btw.

kerem commented

2026-03-01 21:39:44 +03:00

Author

Owner

@icarcal commented on GitHub (Feb 29, 2020):

Hey guys.
I found a new "workaround" for this.

Looking further into the GA expression docs, there are two ways of writing an expression.
From the GA expression docs:

As part of an expression, you may access context information using one of two syntaxes.
Index syntax: github['sha']
Property dereference syntax: github.sha

Since act uses otto to evaluate all expressions, if we write:
steps.yarn_cache.outputs['cache-hit'] != 'true'
instead of
steps.yarn_cache.outputs.cache-hit != 'true'

GA runner accepts it, otto evaluates it correctly, and we can run it both with act and GA

@icarcal commented on GitHub (Feb 29, 2020): Hey guys. I found a new "workaround" for this. Looking further into the GA expression docs, there are two ways of writing an expression. From the [GA expression docs](https://help.github.com/en/actions/reference/contexts-and-expression-syntax-for-github-actions#contexts): >As part of an expression, you may access context information using one of two syntaxes. > Index syntax: `github['sha']` > Property dereference syntax: `github.sha` Since `act` uses [otto](https://github.com/robertkrimen/otto) to evaluate all expressions, if we write: `steps.yarn_cache.outputs['cache-hit'] != 'true'` instead of `steps.yarn_cache.outputs.cache-hit != 'true'` GA runner accepts it, otto evaluates it correctly, and we can run it both with `act` and `GA`

kerem commented

2026-03-01 21:39:44 +03:00

Author

Owner

@cplee commented on GitHub (Mar 2, 2020):

Thanks @icarcal for calling out this workaround! Unfortunately, I think this is as good as it gets for now.

@mced - are you ok closing this given the workaround?

@cplee commented on GitHub (Mar 2, 2020): Thanks @icarcal for calling out this workaround! Unfortunately, I think this is as good as it gets for now. @mced - are you ok closing this given the workaround?

kerem commented

2026-03-01 21:39:44 +03:00

Author

Owner

@mced commented on GitHub (Mar 2, 2020):

I'm ok with the given workarounds, thanks @icarcal @cplee.

@mced commented on GitHub (Mar 2, 2020): I'm ok with the given workarounds, thanks @icarcal @cplee.

kerem commented

2026-03-01 21:39:44 +03:00

Author

Owner

@torbjornvatn commented on GitHub (Mar 6, 2020):

@cplee I found another case where this is an issue and the workaround doesn't work;
When your trying to use someone else's action and it has input parameters with - in them.

name: Test stuff

on:
  - push

jobs:
  build:
    name: Testing Testing
    runs-on: ubuntu-latest
    steps:

    - name: hello
      uses: actions/hello-world-docker-action@master
      with:
        who-to-greet: "World"

which gives the error:

ERRO[0001] Unable to interpolate string '${{ inputs.who-to-greet }}' - [ReferenceError: 'to' is not defined]

@torbjornvatn commented on GitHub (Mar 6, 2020): @cplee I found another case where this is an issue and the workaround doesn't work; When your trying to use someone else's action and it has input parameters with `-` in them. ``` name: Test stuff on: - push jobs: build: name: Testing Testing runs-on: ubuntu-latest steps: - name: hello uses: actions/hello-world-docker-action@master with: who-to-greet: "World" ``` which gives the error: ``` ERRO[0001] Unable to interpolate string '${{ inputs.who-to-greet }}' - [ReferenceError: 'to' is not defined] ```

kerem commented

2026-03-01 21:39:44 +03:00

Author

Owner

@cplee commented on GitHub (Mar 6, 2020):

Confirmed @torbjornvatn :(

I'm really stumped on this one. I'd really rather not have to implement my own parser for GitHub Actions expression language. Open to suggestions.

@cplee commented on GitHub (Mar 6, 2020): Confirmed @torbjornvatn :( I'm really stumped on this one. I'd really rather not have to implement my own parser for GitHub Actions expression language. Open to suggestions.

kerem commented

2026-03-01 21:39:44 +03:00

Author

Owner

@icarcal commented on GitHub (Mar 6, 2020):

@cplee Replace the dot notation with the array notation before evaluate the expression is an option?

@icarcal commented on GitHub (Mar 6, 2020): @cplee Replace the dot notation with the array notation before evaluate the expression is an option?

kerem commented

2026-03-01 21:39:44 +03:00

Author

Owner

@cplee commented on GitHub (Mar 6, 2020):

ya, that may work @icarcal ...would be a rather interesting regex

@cplee commented on GitHub (Mar 6, 2020): ya, that may work @icarcal ...would be a rather interesting regex

kerem commented

2026-03-01 21:39:44 +03:00

Author

Owner

@eventualbuddha commented on GitHub (Mar 31, 2020):

While I agree it would be somewhat annoying to port it to Golang, the expression parser for it is at least open source. You can find the lexer here, for example. It really doesn't look too bad.

@eventualbuddha commented on GitHub (Mar 31, 2020): While I agree it would be somewhat annoying to port it to Golang, the expression parser for it is at least open source. [You can find the lexer here](https://github.com/actions/runner/blob/a5f06b3ec2c138a4a3a03b674e87fa262e1f766f/src/Sdk/DTExpressions2/Expressions2/Tokens/LexicalAnalyzer.cs), for example. It really doesn't look too bad.

kerem commented

2026-03-01 21:39:44 +03:00

Author

Owner

@cplee commented on GitHub (Apr 16, 2020):

Great find @eventualbuddha - would love some help with this one!

@cplee commented on GitHub (Apr 16, 2020): Great find @eventualbuddha - would love some help with this one!

kerem commented

2026-03-01 21:39:44 +03:00

Author

Owner

@Shadowfiend commented on GitHub (May 29, 2020):

Dug a little more at that lexer, looks like the right regex for the actual token would be something like \.([a-zA-Z_][a-zA-Z0-9]*(?:-[a-zA-Z0-9]*)+) (see the legal keyword test for valid keyword contents). Replacing that with .["$1"] should do the trick.

I'll try and do a PR in the next couple of days.

@Shadowfiend commented on GitHub (May 29, 2020): Dug a little more at that lexer, looks like the right regex for the actual token would be something like `\.([a-zA-Z_][a-zA-Z0-9]*(?:-[a-zA-Z0-9]*)+)` (see [the legal keyword test](https://github.com/actions/runner/blob/6c70d53eead402ba5d53676d6ed649a04e219c9b/src/Sdk/DTExpressions2/Expressions2/Sdk/ExpressionUtility.cs#L137-L173) for valid keyword contents). Replacing that with `.["$1"]` should do the trick. I'll try and do a PR in the next couple of days.

kerem commented

2026-03-01 21:39:45 +03:00

Author

Owner

@badouralix commented on GitHub (Jun 24, 2020):

#286 is quite interesting

Here is the code handling the evaluation of the if-expression at high-level : github.com/nektos/act@7cc668707b/pkg/runner/run_context.go (L254-L266)

With this setup, we have expr == "steps.bincache.outputs.cache-hit != 'true'".

This is not properly parsed by Interpolate as it is missing the ${{...}} delimiters ( github actions support this feature though ). By default, Interpolate will return the same output as the input.

So we end up with expr == "Boolean(steps.bincache.outputs.cache-hit != 'true')" which is the input of Evaluate
And it fails evaluating because of the js reference error, so we enter this block : github.com/nektos/act@7cc668707b/pkg/runner/run_context.go (L259-L261)

So here EvalBool returns false.

But if we change just a little bit the if-expression with :

-        if: steps.bincache.outputs.cache-hit != 'true'
+        if: ${{ steps.bincache.outputs.cache-hit != 'true' }}

Then Interpolate can parse its input. It calls Evaluate, which fails for the same reason as before. But the error is caught by Interpolate which will return the empty string because of : github.com/nektos/act@7cc668707b/pkg/runner/expression.go (L65-L67)

So here, we end up with expr == Boolean() ( this is different from the previous case ). It means that we reach : github.com/nektos/act@7cc668707b/pkg/runner/run_context.go (L262-L263)

In particular, we got this debug log line :

DEBU[0003] Expression 'Boolean()' evaluated to 'false'

And EvalBool also returns false.

But the reason is different from the previous case, and the fix will likely be sightly different.

@badouralix commented on GitHub (Jun 24, 2020): #286 is quite interesting Here is the code handling the evaluation of the if-expression at high-level : https://github.com/nektos/act/blob/7cc668707b9c586a45f717301902224bca6d2a12/pkg/runner/run_context.go#L254-L266 --- With this setup, we have `expr == "steps.bincache.outputs.cache-hit != 'true'"`. This is not properly parsed by `Interpolate` as it is missing the `${{...}}` delimiters ( github actions support this feature though ). By default, `Interpolate` will return the same output as the input. So we end up with `expr == "Boolean(steps.bincache.outputs.cache-hit != 'true')"` which is the input of `Evaluate` And it fails evaluating because of the js reference error, so we enter this block : https://github.com/nektos/act/blob/7cc668707b9c586a45f717301902224bca6d2a12/pkg/runner/run_context.go#L259-L261 So here `EvalBool` returns `false`. --- But if we change just a little bit the if-expression with : ```diff - if: steps.bincache.outputs.cache-hit != 'true' + if: ${{ steps.bincache.outputs.cache-hit != 'true' }} ``` Then `Interpolate` can parse its input. It calls `Evaluate`, which fails for the same reason as before. But the error is caught by `Interpolate` which will return the empty string because of : https://github.com/nektos/act/blob/7cc668707b9c586a45f717301902224bca6d2a12/pkg/runner/expression.go#L65-L67 So here, we end up with `expr == Boolean()` ( this is different from the previous case ). It means that we reach : https://github.com/nektos/act/blob/7cc668707b9c586a45f717301902224bca6d2a12/pkg/runner/run_context.go#L262-L263 In particular, we got this debug log line : ```text DEBU[0003] Expression 'Boolean()' evaluated to 'false' ``` And `EvalBool` also returns `false`. But the reason is different from the previous case, and the fix will likely be sightly different.

Rows
Columns

[GH-ISSUE #104] Unable to interpolate string - hyphenated variables #69