mirror of
https://github.com/nektos/act.git
synced 2026-04-26 09:25:54 +03:00
[GH-ISSUE #1071] Error in if-expression #619
Labels
No labels
area/action
area/cli
area/docs
area/image
area/runner
area/workflow
backlog
confirmed/not-planned
kind/bug
kind/discussion
kind/external
kind/feature-request
kind/question
meta/duplicate
meta/invalid
meta/need-more-info
meta/resolved
meta/wontfix
meta/workaround
needs-work
pull-request
review/not-planned
size/M
size/XL
size/XXL
stale
stale-exempt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/act#619
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jonny7 on GitHub (Mar 23, 2022).
Original GitHub issue: https://github.com/nektos/act/issues/1071
Thanks very much for this project 🙂
System information
Expected behaviour
I have been running this element of a pipeline fine with
0.2.25last night. I've just updated and I'm getting errors now around the if statement. So I would expect that this would continue to work and it works on GitHub, see here for reproducibleActual behaviour
Calling
fails with
Workflow and/or repository
Repo has a working example that works on GH and did on 0.2.25 of act. The relevant workflow is this
Steps to reproduce
The pipeline I'm using it with was based on
pull_request, soact pull_request.actoutput@ChristopherHX commented on GitHub (Mar 23, 2022):
Yes it's a bug, the new expression evaluator should not return such errors.
Workaround, it probably take some months till v0.2.27
You can just create the missing object
pull_request.json
act pull_request -e pull_request.jsongithub.event.pull_request.labels.*.namedidn't work in act 0.2.25, because it was misinterpreted asgithub.event.pull_request.labels['*'].name.@jonny7 commented on GitHub (Mar 24, 2022):
Thanks @ChristopherHX
This workaround is cool right now for me
@jonny7 commented on GitHub (Mar 24, 2022):
I should leave open as it is a bug - my mistake
@dror-weiss commented on GitHub (Apr 5, 2022):
Same here, in a more widespread use case such as searching for a special commit message:
The
commitselement doesn't exist in apull_requestevent, so this should be relatively easy to fix, IMO.