Have distinct differense between skipped and canceled status

[6543]

regression of #6176

fix #6264

[qwerty287]

I intentionally left that "skipped" because the step actually was skipped, but due to cancellation.

[6543]

well as you added a distinct cancle state we could argue that it was cancled

we already differ between cancled and killed, with your argument we should also not mark it as killed but cancled !?

i think not hiding info to the user is a god thing in this case

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 32.41%. Comparing base (9f9aa72) to head (622c290).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6267   +/-   ##
=======================================
  Coverage   32.41%   32.41%           
=======================================
  Files         420      420           
  Lines       28318    28318           
=======================================
  Hits         9180     9180           
  Misses      18289    18289           
  Partials      849      849           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[qwerty287]

Fine for me. Untested from my side. I still think we somehow have to make clear what "cancelled" means,but that's likely much harder

[6543]

I still think we somehow have to make clear what "cancelled" means,but that's likely much harder

agree on that ... my only idea is to add a link to [read more] in the text that links to the docs ... and explain it in the docs or so

[anbraten]

Does the user even care about the difference of skipped / canceled / killed? I would like to know was my step started and has it finished? Was it successful or not? Most of the details are clear from the context in the UI. Has a duration and some logs => step was at least started even if it never finished. Having to understand the specific difference of a status makes it rather complicated for a user to know what happened (seems most maintainers including me run into the same issue).

Actually I am wondering why we show skipped steps at all. We don't show skipped workflows / steps from (depends_on) 🤔 Is it even really helpful? Probably not.

[qwerty287]

If a workflow is skipped due to the status condition it's shown as well.