mirror of
https://github.com/nektos/act.git
synced 2026-04-26 09:25:54 +03:00
[GH-ISSUE #2152] Inconsistent and sometimes broken expression evaluation #1029
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#1029
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 @iby on GitHub (Jan 12, 2024).
Original GitHub issue: https://github.com/nektos/act/issues/2152
Bug report info
Command used with act
Describe issue
Check out the following workflow. There are 3 scenarios all of which should work. I'm trying to use a variable with expression to control job execution via
if.But the first one doesn't, where the variable uses an expression, and then there's another expression references it. Interestingly, the 2nd variation does work:
But everything works as expected with plain variables, e.g.,
VAR: 'foo'vs.VAR: ${{ true && 'foo' || 'bar' }}.I'm guessing
actmight be interpreting values "on demand" and this doesn't happen as expected inside a "nested" expression?Link to GitHub repository
No response
Workflow content
Relevant log output
Additional information
No response
@iby commented on GitHub (Jan 12, 2024):
Edit: The second option actually completely incorrectly evaluates to true… 😰
@ChristopherHX commented on GitHub (Jan 12, 2024):
All posted workflows in this issue are incorrect and wouldn't work in official GitHub Actions.
envis not available injobs.*.if, the bad case to check this is not implemented in act.In my opinon that they evaluate to true is correct, because this matches a well known bug in GitHub Actions Job If and act is expected you to help to detect that locally.
If you tell me that GitHub fixed that bug together with a reproducable workflow, then yes act should follow the fix of GitHub Actions.
@iby commented on GitHub (Jan 12, 2024):
Hey @ChristopherHX! Thanks for the quick feedback and insights!
Ha! I rely too much on
actlately to avoid testing it on GitHub… 🥲In case anyone else stumbles upon this, see context availability docs.
P.S.
envcontext is available insidejobs.<job_id>.steps.if. I guess a good workaround forjobs.<job_id>.ifis to use an earlier job output.@iby commented on GitHub (Jan 12, 2024):
@ChristopherHX on the same note, does
actperforms any workflow file validation? I was going to suggest using rhysd/actionlint, but looks like it's already in dependencies. Butacthasn't failed the workflow file validation when I ran it, like GitHub does, or like actionlint does in their playground which matches GitHub. Would be fantastic to have that behavior out of the box?@ChristopherHX commented on GitHub (Jan 12, 2024):
Expression parsing logic is used by act from actionlint. The rest is still completly independent.
For example act might run workflows, actionlint would complain about if actionlint is right or not depends on the used functionality.
The best linter is the official GitHub Actions Vscode extension, because it uses a ts port of the exact same parser used by the GitHub Actions Service.
It also autocompletes your expressions.
Sorry, but nektos/act is not my own project, e.g. I depend on other peoples approval to do anything here
Lately I'm struggeling to get two reviews in an acceptable time (within 30days) for new features in act, while the old review requirements are still intact. I'm currently avoiding starting new features, bejond these which still await reviews since a couple of months, to avoid investing work in potenteally abandoned features due to missing reviewers