fix(ci): make dependency audit non-blocking - #2048

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Show the relevant workflow section with line numbers.
sed -n '150,210p' .github/workflows/main.yml | cat -n

# Inspect whether continue-on-error appears at job or step scope elsewhere in the workflow.
rg -n "continue-on-error" .github/workflows/main.yml

Repository: unraid/api

Length of output: 2836

🌐 Web query:

GitHub Actions job-level continue-on-error step failures workflow behavior

💡 Result:

In GitHub Actions, the behavior of continue-on-error differs significantly depending on whether it is applied at the step level or the job level [1][2]. Step-Level Behavior When you set continue-on-error: true on a specific step, the workflow will continue to the next step even if that step fails [3][2]. The failed step will be reported with a "success" or "neutral" outcome in the workflow logs (though its outcome will be failure, its conclusion will be success), which allows subsequent steps to execute [2]. - If you use a conditional like if: failure in a subsequent step, it may not trigger as expected because the previous step is technically not marked as a "failure" by the runner [2]. - To check if a specific step with continue-on-error failed, you should use the step's outcome context: if: steps.<step_id>.outcome!= 'success' [2]. Job-Level Behavior Applying continue-on-error: true at the job level is designed to allow the workflow to proceed with other jobs even if the current job fails [4][5]. However, unlike step-level usage, this does not "silently" hide the failure of the job itself in the GitHub UI [5]. A job with continue-on-error: true will still be reported as a failure in the pull request and workflow summary UI if any of its steps fail, even if the workflow continues to execute subsequent dependent jobs [5]. Key Considerations - Status Checks: Because job-level continue-on-error still marks the job as a failure in the UI, it can impact status checks and branch protection rules that require specific jobs to pass [5]. - Workarounds: If you need to detect a failure in a step while still allowing the job to continue, or if you need to ensure a job fails despite a "continue-on-error" setting, you can manually exit the job in a subsequent step (e.g., run: exit 1) based on the outcome of the previous step [3][2].

Citations:

• 1: https://stackoverflow.com/questions/79803748/github-actions-job-matrix-with-continue-on-error-fails
• 2: Wrong behaviour when combining 'continue-on-error' and 'failure()' in subsequent steps actions/toolkit#1034
• 3: https://stackoverflow.com/questions/58858429/how-to-run-a-github-actions-step-even-if-the-previous-step-fails-while-still-f
• 4: continue-on-error should not return success in needs_job_result actions/toolkit#1739
• 5: Wrong behaviour when combining 'continue-on-error' and 'failure()' in subsequent steps actions/toolkit#1034

🌐 Web query:

site:docs.github.com GitHub Actions continue-on-error job level step level semantics

💡 Result:

In GitHub Actions, the continue-on-error property functions differently depending on whether it is applied at the step level or the job level [1][2]. Step-Level Semantics When continue-on-error is set to true for an individual step, it prevents the job from failing when that specific step fails [1][2]. - The workflow execution continues to subsequent steps in the job [1][2]. - The outcome property of the step will be failure, but the final conclusion property will be success [3][4][5]. - This allows the job to proceed even if a non-critical step fails [6]. Job-Level Semantics When continue-on-error is set to true at the job level, it prevents the entire workflow run from failing if that specific job fails [1][7][8]. - If a job with continue-on-error: true fails, the job itself is considered successful regarding the overall workflow status [1]. - This is particularly useful when using a job matrix where certain experimental jobs might fail without needing to invalidate the entire workflow run [1][7][8]. In summary, step-level continue-on-error keeps a job running despite a failing step, while job-level continue-on-error keeps a workflow running despite a failing job [1]. Both properties accept boolean values and can be dynamically set using expressions [9][7][8].

Citations:

• 1: https://docs.github.com/en/enterprise-server@3.0/articles/workflow-syntax-for-github-actions
• 2: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
• 3: https://docs.github.com/en/enterprise-server@3.17/actions/reference/workflows-and-actions/contexts
• 4: https://docs.github.com/enterprise-server@3.0/actions/learn-github-actions/contexts
• 5: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
• 6: https://docs.github.com/en/actions/tutorials/build-and-test-code/python
• 7: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations
• 8: https://docs.github.com/actions/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow
• 9: https://docs.github.com/en/enterprise-server@3.20/actions/reference/workflows-and-actions/expressions