act: Unable to interpolate string - hyphenated variables

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.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 9
  • Comments: 17 (9 by maintainers)

Most upvoted comments

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

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

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.

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?

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.