-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Expression evaluator fixes #1009
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
Conversation
Errors should always be logged with an error level and not debug level. Since the error is returned here, it will be logged later as an error. Presumably this was a leftover from debugging the executor chain in: PR: nektos#971
|
@ChristopherHX do you remember why you added this debug log in #971 7dbf3fc#diff-fa62a470d83900f015861d603c59c5e371354fb0cdf36089a274d40ee409029eR139? |
|
@ZauberNerd this pull request has failed checks 🛠 |
|
I restored the function 1:1 as it was prior running steps after job failure https://github.com/nektos/act/blob/v0.2.25/pkg/common/executor.go#L139 I'm not the original author of this debug print
Yes it will eventually get printed. I think it good for debugging to always print any error of the then executor. |
In my opinion debug logging should be used to provide more information that otherwise isn't visible in order to be able to understand what is happening. Below is the test run of https://github.com/nektos/act/pull/971/files#diff-4526efc54b2af950bff29a71c13adadb9f22132374291f264c843cc3cfd51d21 |
Codecov Report
@@ Coverage Diff @@
## master #1009 +/- ##
==========================================
+ Coverage 57.50% 58.55% +1.04%
==========================================
Files 32 34 +2
Lines 4594 4625 +31
==========================================
+ Hits 2642 2708 +66
+ Misses 1729 1690 -39
- Partials 223 227 +4
Continue to review full report at Codecov.
|
you could make it a trace instead debug |
|
@ChristopherHX @catthehacker so what's the status here? Should I:
In case you'd like to keep a log in the |
|
I don't really have any preference, I'll leave it up to you |
ChristopherHX
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works: I'm ok with removing the debug print. You won't need to address my review comment, which is just an example ( and a bug in act ) why I prefer to use actions/runner locally.
In a later change, we might want to connect this error to an actual job.
Error: ❌ Error in if-expression: "if: fromJSON('{}')||github.event.pull_request || !github.event.pull_request
" (Unable to map type 'map[]' to boolean for 'fromJSON('{}')||github.event.pull_request || !github.event.pull_request
')
pkg/runner/expression.go
Outdated
| } | ||
| default: | ||
| return false, fmt.Errorf("Unable to map return type to boolean for '%s'", expr) | ||
| return false, fmt.Errorf("Unable to map type '%t' to boolean for '%s'", evaluated, expr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought the default case is impossible to reach for a conforming evaluator.
Any Object != null => true, except empty string
if: github.event.pull_request( true if PR )if: fromJSON('{}')( always true )
This weird workflow only fails in act, the last step is expected to run
on:
- push
- pull_request
jobs:
m:
runs-on:
- ubuntu-latest
steps:
- run: |
echo PR!
shell: bash
if: |
github.event.pull_request
- run: |
echo Push!
shell: bash
if: |
!github.event.pull_request
- run: |
echo empty obj!
shell: bash
if: |
fromJSON('{}')There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, I'll update the function to handle maps.
We've seen this issue when the env map is not set-up properly, i.e. when the env map is nil, EvalBool might return nil, which should be handled as a falsy value.
Stop running the workflow in case an expression cannot be evaluated. Fixes: nektos#1008
It looks like having an expression inside double quotes inside the expression syntax is not valid: https://github.com/ZauberNerd/act-test/actions/runs/1881986429 The workflow is not valid. .github/workflows/test.yml (Line: 10, Col: 13): Unexpected symbol: '"endsWith'. Located at position 1 within expression: "endsWith('Hello world', 'ld')"
60d9ad3
5cea30c to
60d9ad3
Compare
|
@ChristopherHX @catthehacker I've updated this PR to use the |
KnisterPeter
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
|
@ZauberNerd - is this a breaking change? looks like the tests had to be updated from |
These workflows are invalid according to GitHub and strings can only use single quotes: https://docs.github.com/en/actions/learn-github-actions/expressions#literals Here's a workflow run of the "issue-597" workflow: https://github.com/ZauberNerd/act-test/actions/runs/1889956547 Also, it doesn't look like they worked on master either, just the error while parsing the With these changes it looks like this: |
ChristopherHX
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also wouldn't classify the test workflow corrections as a breaking change, since it never used to work on github. I even blindly duplicated the invalid if in the composite test, in the past assuming these were valid.
I would say deleting container on workflow failure was a breaking change introduced after 0.2.25, no tests no ci failure.
|
Thanks @ZauberNerd - solid answer :) |
This PR contains a few fixes and improvements for the new expression evaluator:
IsTruthy()function from theexprparserpackage insideEvalBool()Fixes: #1008
Ref: #971