job.name expression not evaluated when job skipped #13261

lpeabody · 2022-03-22T14:57:00Z

lpeabody
Mar 22, 2022

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:

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

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 · 2022-03-25T13:58:00Z

chrispat
Mar 25, 2022

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.

4 replies

lpeabody Mar 25, 2022
Author

Great thank you!

Ginxo Dec 21, 2022

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

RubenWeijers-TomTom Jul 24, 2023

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:

SirzBenjie May 30, 2025

Would really like an update for this.... It was triaged 2 years ago?

eilonash92 · 2023-12-25T16:18:04Z

eilonash92
Dec 25, 2023

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

0 replies

yarden2k3 · 2024-05-27T13:03:52Z

yarden2k3
May 27, 2024

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

0 replies

mikita-sakalouski · 2024-05-30T14:20:30Z

mikita-sakalouski
May 30, 2024

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

0 replies

tuxity · 2024-07-09T08:22:44Z

tuxity
Jul 9, 2024

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

0 replies

AlexanderBelokon · 2024-08-03T20:43:18Z

AlexanderBelokon
Aug 3, 2024

@chrispat Any updates?

3 replies

samus-aran Aug 9, 2024
Maintainer

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 Aug 15, 2024

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 Aug 16, 2024

+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 · 2024-12-16T14:06:58Z

kostyay
Dec 16, 2024

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

0 replies

axten · 2025-05-02T12:17:53Z

axten
May 2, 2025

any updates here?

0 replies

djonestelus · 2025-05-07T00:56:39Z

djonestelus
May 7, 2025

How is this still not fixed?

Does anyone have a workaround?

0 replies

ablenesi · 2025-12-30T22:28:32Z

ablenesi
Dec 30, 2025

2026 around the corner still no resolution

0 replies

job.name expression not evaluated when job skipped #13261

Uh oh!

Uh oh!

Replies: 10 comments · 7 replies

Uh oh!

Uh oh!

lpeabody Mar 25, 2022 Author

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

samus-aran Aug 9, 2024 Maintainer

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Replies: 10 comments 7 replies

lpeabody Mar 25, 2022
Author

samus-aran Aug 9, 2024
Maintainer