Conversation
| # Execute lychee | ||
| eval lychee ${FORMAT} --output ${LYCHEE_TMP} ${ARGS} | ||
| exit_code=$? | ||
| LYCHEE_EXIT_CODE=$? |
There was a problem hiding this comment.
I change it to uppercase to imply the variable is immutable and does not describe the exit code of entrypoint.sh.
YDX-2147483647
changed the title
fail: false effective even when failIfEmpty: true
YDX-2147483647
force-pushed
the
fail
branch
2 times, most recently
from
c65938a to
769af09
Compare
This commit also makes sure `outputs.exit_code` is “The exit code returned from Lychee”. `failIfEmpty` no longer changes it to `1`. Relevant docs: - [Setting exit codes for actions - GitHub Docs](https://docs.github.com/en/actions/sharing-automations/creating-actions/setting-exit-codes-for-actions) - [exit - POSIX Programmer's Manual](https://manned.org/exit.1posix) Relates to lycheeverse#86, lycheeverse#128, lycheeverse#145, lycheeverse#245, and lycheeverse#251.
The previous expression always gives `false`. Both `env.exit_code` and `env.lychee_exit_code` are `null`, probably since the docker→composite refactor lycheeverse#128. When GitHub evaluates the expression, it finds the types do not match, and coerces them to number, namely, `null` → `0`. See [Evaluate expressions in workflows and actions - GitHub Docs](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#operators). Relates to lycheeverse#253.
|
Now it passes the $ nix-env -iA nixpkgs.act
$ act -W .github/workflows/test.yml # with medium size image
By the way, as lychee is a rust project, I bet those two bugs would never happen if variables are immutable by default and |
Edited from lycheeverse#251. Co-Authored-By: Sebastiaan Speck <[email protected]>
|
So I've just done it. I (✅ = already covered, 🌟 = this PR)
|
|
Thanks for fixing and for documenting the process so neatly. Very well done! 🌟 |
|
|
||
| - name: Create Issue From File | ||
| if: env.exit_code != 0 | ||
| if: ${{ steps.lychee.outputs.exit_code }} != 0 |
There was a problem hiding this comment.
@YDX-2147483647, this seems to have led to a false-positive issue creation here: #264
Note that there were no issues with the check run, but it still created the issue.
There was a problem hiding this comment.
Oh, sorry… I guess ${{ steps.lychee.outputs.exit_code }} != 0 evaluates to "0 != 0" (a string), and becomes true when GitHub coerces its type.
So it should be if: steps.lychee.outputs.exit_code != 0 or if: ${{ steps.lychee.outputs.exit_code != 0 }}. Not sure, however. I'll test it in my own repo later (in one or two days).
There was a problem hiding this comment.
I have just tested it, and it works for both success and failure. Please see #265.
`${{ steps.lychee.outputs.exit_code }} != 0` evaluates to `"0 != 0"` (a string), and becomes `true` when GitHub coerces its type.
Relates-to: lycheeverse#262
3 participants
fix: Make
fail: falseeffective even whenfailIfEmpty: trueThis commit also makes sure
outputs.exit_codeis “The exit code returned from Lychee”.failIfEmptyno longer changes it to1.Relevant docs:
Relates to Add
failIfEmptyargument (fixes #84) #86, Dockerless #128, Propagate lychee exit code #145, Set exit_code correctly as output #245, and test: testfail-argument #251.fix: Update
env.exit_codetooutputs.exit_codeThe previous expression always gives
false.Both
env.exit_codeandenv.lychee_exit_codearenull, probably since the docker→composite refactor Dockerless #128. When GitHub evaluates the expression, it finds the types do not match, and coerces them to number, namely,null→0.See Evaluate expressions in workflows and actions - GitHub Docs.
Relates to Fix variable name #253.
No doc update required.