-
Notifications
You must be signed in to change notification settings - Fork 954
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
Job-level "if" condition not evaluated correctly if job in "needs" property is skipped #491
Comments
I think this meant to be a feature actually, but it's too subtle in my opinion - it left me scratching my head for an hour over why my workflow step wasn't running. From https://docs.github.com/en/actions/learn-github-actions/expressions#job-status-check-functions:
I would have expected the default value of |
This problem is still present on version 2.273.1 |
Stumbled upon this while looking for a different issue, but thought I'd throw in my perspective on the matter.
The only thing I think would be appropriate and appreciated is a note about this functionality in the docs for the workflow job |
This comment has been minimized.
This comment has been minimized.
* Only run bats diagnostics on failure * Try a different failure syntax * Third time lucky? * Always run if we failed, even though the previous step failed As per actions/runner#491 * Try and fix the logic again * Simplify the testing * Try a different way of checking for failure * Try matching on any status, is matrix confusing things? * Drop the matrix for now * Fix the workflow syntax * Different variable name * Undo the hacking, matrix the bats tests * Actually run bats if we need to * Undo the deliberate test breakage
According to actions/runner#491 we need to include an `always()` so that the if statement is evaluated even when one of the needed jobs is skipped.
* Update vscode-languageclient to v7.0.0 * Fix build triggers According to actions/runner#491 we need to include an `always()` so that if statements evaluate to `true` even when one of the needed jobs is skipped.
This also had me scratching my head for a very long time. It's completely counter-intuitive you have to use any of the status functions. Maybe this is from before the It would hope this requirement can be removed, because it just doesn't really make any sense. Why does one have to do |
I think the issue is that Those in the first category feel it is illogical because they are using it simply to order their jobs, while those using it for the original intended purpose I would guess generally find it makes sense. A job that Perhaps some other form of sequencing should be introduced to alleviate this confusion, or as I suggested in my last comment just making this much more clear in the docs could probably do the same work. |
In a similar case, I had a conditional job jobs:
...
Z:
runs-on: ubuntu-latest
needs: [A, B, C]
if: |
always() &&
(needs.A.result == 'success' || needs.A.result == 'skipped') &&
(needs.B.result == 'success' || needs.B.result == 'skipped') &&
(needs.C.result == 'success' || needs.C.result == 'skipped') &&
my_original_conditional()
steps:
- name: blah
... Very verbose and I'm probably not using workflows as intended, but it works! 😅 |
i also find this behavior burdensome and confusing. for example:
my expectation from working with DAG based systems is that a parent node should determine a child node directly. why does a child node have to know about grandparents in order to execute a task that depends ONLY ON THE PARENT running? can't see the logic here.. |
Idea 💡What if there was a new field called
This would be effectively equivalent to @andreykaipov's solution, but less verbose. Example: jobs:
...
C:
runs-on: ubuntu-latest
follows: [A, B]
if: my_original_conditional()
steps:
- name: blah
... |
@PaulRBerg do you understand the reasoning behind why I'm trying to think of if I'm happy to be shown the light though... |
I think following example will produce expected behavior of original question. job_d:
runs-on: ubuntu-latest
needs: [job_a, job_b]
if: |
always() &&
!contains(needs.*.result, 'failure') &&
!contains(needs.*.result, 'cancelled') &&
needs.job_a.outputs.truthy_string
steps:
- run: echo "${{ toJSON(needs) }}"
|
@gad2103 I think you're arguing a different issue here. This issue is about |
I created a discussion. |
Not working, build is being skipped. Related: actions/runner#491
I believe the same result can be achieved like this: jobs:
...
Z:
runs-on: ubuntu-latest
needs: [A, B, C]
if: always() && !cancelled() && !failure() && my_original_conditional()
steps:
- name: blah
... Essentially, we would need a condition I am not 100% sure this works exactly the same in more complex setups with multiple levels of dependencies, but during my testing it seemed to work. |
Additional adjustment needed in order to prevent actions/runner#491
* fix(MCPE-3498): Adjust job conditions Additional adjustment needed in order to prevent actions/runner#491 * fix(MCPE-3498): Clean-up
This contains several conditions that appear to be illogical, but are required by github actions. For some background this issue can be read: actions/runner#491 `always()`: Imagine two packages. Package "a" and package "b". "b" depends on "a" and we want to automatically release "a" and "b" using release please. We make "b" `needs` "a", so that "b" will build after "a". But if we do that, then "b" will not build unless "a" also builds. We often need to release "b" even though there are no changes to "a". By using `if: always()` we can cause "b" to run after "a" even when "a" doesn't run. `failure()` and `canceled()`. With `always()` package "b" will be built and released even if package "a" failed to build. You would expect that to only require `failure()`, but it seems that it only works if you have `canceled()` as well. (It may be we don't actually need failure.) We want the build order to be like this. ![dep-order-2 drawio](https://github.com/user-attachments/assets/7d499cdb-1163-442b-aefa-7bac01ad560b)
Describe the bug
If a job
needs
a prior job which has been skipped, theif
condition for the dependent job may behave unexpectedly under some conditions. (unsure if condition is evaluated incorrectly or if it's not evaluated at all)To Reproduce
Steps to reproduce the behavior:
Given a workflow such as this (where job_b needs to complete or be skipped before subsequent jobs run, but subsequent jobs don't depend upon any outputs from job_b)
Examining the output of this workflow, job_a will always run, job_b will always be skipped, job_c will always be skipped, and job_d will run.
The only difference between job_c and job_d is the addition of
always() &&
to theif
condition.Expected behavior
If a job-level conditional evaluates to
true
, the job should run after allneeds
'd jobs have completed or been skipped.Both job_c and job_d should run. The
always() &&
should not be required for job_c, since it doesn't change the ultimate true/false result of the conditional.OR documentation should be updated to indicate this is expected behavior. The current docks simply says of job
needs
(emphasis added):Runner Version and Platform
Version of your runner?
Unsure - I'm only running via Github Actions, not using a self-hosted runner.
OS of the machine running the runner? OSX/Windows/Linux/...
Linux: ubuntu-latest
What's not working?
Jobs are being skipped even when the job-level conditional evaluates to
true
.Job Log Output
Because the job is skipped entirely, there is no job-level output, even if the appropriate DEBUG secret is set.
Runner and Worker's Diagnostic Logs
As above, there is no additional output, even if the appropriate DEBUG secret is set.
The text was updated successfully, but these errors were encountered: