-
-
Notifications
You must be signed in to change notification settings - Fork 53
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
Set exit_code correctly as output #245
Conversation
Thanks! Can you also add a test which checks that the exit code works to https://github.com/lycheeverse/lychee-action/blob/master/.github/workflows/test.yml? Something like that: - name: Test exit code output (expecting failure)
id: lychee_exit_test
uses: ./
with:
args: -- inputdoesnotexist
continue-on-error: true
- name: Check exit code
run: |
echo "Lychee exit code: ${{ steps.lychee_exit_test.outputs.exit_code }}"
if [[ "${{ steps.lychee_exit_test.outputs.exit_code }}" == "1" ]]; then
echo "Lychee correctly failed with exit code 1"
else
echo "Unexpected exit code: ${{ steps.lychee_exit_test.outputs.exit_code }}"
echo "Expected exit code 1 for failed check"
exit 1
fi |
I think we need to test if lychee failed with an exit code other than 0 in case of error. Right now you're testing for 0, which is the default and should always work because otherwise the GitHub workflow stops. Did you try the code snippet I posted? 🤔 |
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.
lgtm thanks!
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.
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.
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.
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.
- **fix: Make `fail: false` effective even when `failIfEmpty: true`** 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 #86, #128, #145, #245, and #251. - **fix: Update `env.exit_code` to `outputs.exit_code`** The previous expression always gives `false`. Both `env.exit_code` and `env.lychee_exit_code` are `null`, probably since the docker→composite refactor #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 #253. Co-authored-by: Sebastiaan Speck <[email protected]>
There is specific code in git-scm.com's deploy workflow to open a ticket whenever broken links were detected, and to close such a ticket when no broken links were detected. However, as per lycheeverse/lychee-action#265 the way we checked for this was incorrect: `env.lychee_exit_code` had was correct, until lycheeverse/lychee-action#245 broke it by way of fixing another bug. This was the reason why the broken link that was found and reported in https://github.com/git/git-scm.com/actions/runs/13544529063/job/37852881418#step:3:135319 never made it into a GitHub issue, even if that had been the intention. For the record, I worked on a fix for this broken link and opened jnavila/git-manpages-l10n#131 to incorporate that fix. What prevented this broken link from being detected before above-mentioned deployment is the fact that before git#1953 was merged, the `git-scm.com` deployment used `http://` in the base URL, and hence the `--remap` option used in the deployment workflow mapped all http://git-scm.com links to local files, whereas now the `https://` base URL is used and https://git-scm.com links are mapped, including the offending one. In any case let's fix opening/closing the "broken link" issues. Signed-off-by: Johannes Schindelin <[email protected]>
There is specific code in git-scm.com's deploy workflow to open a ticket whenever broken links were detected, and to close such a ticket when no broken links were detected. However, as per lycheeverse/lychee-action#265 the way we checked for this was incorrect: `env.lychee_exit_code` had was correct, until lycheeverse/lychee-action#245 broke it by way of fixing another bug. This was the reason why the broken link that was found and reported in https://github.com/git/git-scm.com/actions/runs/13544529063/job/37852881418#step:3:135319 never made it into a GitHub issue, even if that had been the intention. For the record, I worked on a fix for this broken link and opened jnavila/git-manpages-l10n#131 to incorporate that fix. What prevented this broken link from being detected before above-mentioned deployment is the fact that before git#1953 was merged, the `git-scm.com` deployment used `http://` in the base URL, and hence the `--remap` option used in the deployment workflow mapped all http://git-scm.com links to local files, whereas now the `https://` base URL is used and https://git-scm.com links are mapped, including the offending one. In any case let's fix opening/closing the "broken link" issues. Signed-off-by: Johannes Schindelin <[email protected]>
echo "lychee_exit_code=$exit_code" >> $GITHUB_ENV | ||
echo "exit_code=$exit_code" >> $GITHUB_OUTPUT |
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.
Please note that this broke the link checking logic of https://git-scm.com/, where it used env.lychee_exit_code
to determine whether to open or close tickets (it will be fixed once git/git-scm.com#1960 is merged).
A better idea would have been to keep the GITHUB_ENV
call and add the GITHUB_OUTPUT
, then announce the environment variable as deprecated, then in a much later release remove support for the environment variable.
But even in https://github.com/lycheeverse/lychee-action/releases/tag/v2.0.0, I did not see any note about this, which is the reason why I had missed this breaking change.
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.
Sorry about that. You're right.
We could add it back in case there are still users out there who are not aware of the breaking change. I've updated the release notes, but I doubt that anyone will find them.
Fixes #244