job.name expression not evaluated when job skipped

[lpeabody]

See original issue that was closed actions/runner#1215.

When a job is skipped, if it's name contains an expression then it is not evaluated. It makes sense, but from a UX perspective it is not ideal.

To reproduce:

1. Have a workflow such as below:

name: Example Workflow
on:
  workflow_dispatch:
jobs:
  Services:
    if: false == true
    name: ${{ github.job }}
    runs-on: ubuntu-latest
    steps:
      - name: Hello World
        run: echo Hello World

2. Run the workflow manually. The result is as below.

Additional example:

on:
  push:
    branches:
      - main
  workflow_dispatch:
    inputs:
      do-backup:
        description: Whether or not to make a backup before deploying.
        required: true
        type: choice
        default: 'false'
        options:
          - 'true'
          - 'false'
      environment:
        description: The environment to deploy to.
        required: true
        default: wwnewdev
        type: choice
        options:
          - wwnewdev
          - wwnewstg
          - wwnewprod

env:
  DEPLOYMENT_ENVIRONMENT: ${{ github.event.inputs.environment || 'wwnewdev' }}

jobs:
  backup:
    name: Backup ${{ github.event.inputs.environment }}
    uses: ./.github/workflows/backup.yml
    # Always backup production.
    if: ${{ github.event.inputs.do-backup == 'true' || github.event.inputs.environment == 'wwnewprod' }}
    with:
      environment: ${{ github.event.inputs.environment }}
  ...

After a push to main you get this UI output:

When manually run via workflow_dispatch, everything looks dandy in the UI.

Ideally, instead of Backup ${{ github.event.inputs.environment }} in the left-hand sidebar, it would say Backup wwnewdev somehow (I understand you can't use the env context in the job name, otherwise I would use that). Also, it would be ideal if in the job flow chart area it would be labeled Backup wwnewdev / Backup.

I understand that if a job is determined to be skipped then further evaluation does not make sense from a processing perspective so this is likely a "feature", but from a UX perspective it is annoying and can cause confusion.

Given the current state, is there any way to work around this to have some kind of graceful fallback? Is there any way to set a job's name dynamically if it is skipped? What have others done to work around this dilemma?

[chrispat]

Thank you for the feedback.

All of these macro replacements and evaluation the condition are done before the job is assigned to a runner. The idea is not spin compute on VMs if we don't have to. However, for some of the known values and particularly those in the UI we should go ahead and do the replacement.

I have filed an issue and we will triage it.

[lpeabody]

Great thank you!

[Ginxo]

thanks @chrispat do you have the link for the issue or any status updating ?

[RubenWeijers-TomTom]

Hi, is there an update for this? This prevents jobs that are marked as required to pass as checked when the job is skipped

vs

Removing the inputs from the job name makes the side-bar kinda unusable:

[eilonash92]

@chrispat Any update on this?
Trying to change in the UX the job name dynamically

[yarden2k3]

Any update on this? Can the issue be attached to this discussion?

[mikita-sakalouski]

It will be nice to have fallback value if job is skipped based on if condition

[tuxity]

Hello! Could we have the link to issue @chrispat please to track state/progress. Thanks

[AlexanderBelokon]

@chrispat Any updates?

[samus-aran]

Hi there,

Please note, contacting any member of GitHub Staff via unsolicited mentions or pings is strongly discouraged and may be considered a violation of our prohibition against harassment. Please review our Code of Conduct for more information.

Let's work together to keep GitHub Community a place where people feel safe to participate by being respectful of them and their time.

Any repeat and future violations may result in a temporary or indefinite block from the Community. Thanks for understanding.

[AlexanderBelokon]

Got you, no more unsolicited mentions.

While you're here, would you say that ignoring the question for over two years and only jumping in to cite the Code of Conduct when members of the community are asking for promised updates is respectful to community members, their time and fosters participation?

Thanks for the threat by the way, I feel safer already!

[Ginxo]

+1 to @AlexanderBelokon
I know you github people have to keep the mass of people under control, but in this case people from the community is trying their best to keep this alive in the best way people knows.
I would suggest samus-aran (I'm not mentioning anyone 😎 😅 ) to tweak last part of your message to not sound so like a threat in the future.
Anyway we are all in the same boat 😉

[kostyay]

Any updates on this? It's quite annoying that it is not evaluated