[Bug] Does not work in reusable workflows

[qoomon]

the job id can not be determined if the action is part of a reusable workflow.

The problem seems to be that the actual job name is something like <main workflow job> / <reusable workflow job>

[daleyjem]

Thanks @qoomon
I'll see if I can figure out what you mean, but in the meantime, can you provide some more reproducibility details? I haven't used reusable workflows before?

[daleyjem]

Ok. I see what you're talking about. One caveat of a reusable workflow is that the context provided by Github/Octokit is inherited from the parent workflow. It doesn't show as workflow_call... which would allow me to make more automatic assumptions.

You pretty much said what is needed to make it work. Set your job_name input to <main workflow job> / <reusable workflow job>.

Unless you have a better proposal, I may opt to just adding documentation of how to use the action when inside of a workflow_call.

[qoomon]

see https://github.com/qoomon/actions--context?tab=readme-ov-file#usage-within-reusable-workflows

[qoomon]

Also see my PR to fix this problem in the github action runner actions/runner#3489

[jeremy-daley-kr]

Also see my PR to fix this problem in the github action runner actions/runner#3489

Can you give me the TL;DR? I'm still not sure what your actual recommendation is. Is this system.jobDisplayName available in the context object or elsewhere?

If it's easier to submit a PR here, or paste a code snippet in the context of this repo, I can certainly look at it.

[c3charvat]

@jeremy-daley-kr actions/runner#3489 is the PR.
I have been involved with tangentially with @qoomon a bit on this. @qoomon Correct me if i am wrong.
TL;DR: We are trying to resolve job URLs for a given job in a reusable workflow. There is nothing to match to in the job api (https://docs.github.com/en/rest/actions/workflow-jobs?apiVersion=2022-11-28#get-a-job-for-a-workflow-run) that readily available in the environment.

Not Short, sadly too long full detail version:
We are trying to resolve job URLs for a given job in a reusable workflow/matrix.
Since we don't have the FULL job name readily available to us in we have to do something like:
https://github.com/qoomon/actions--context/blob/402df64fd4c405e739f0e60e9ed0987c56013605/lib/actions.ts#L203-L227
to build the absolute job name.
Then search for it in the API context..

Up to this point it seems like a quality of life issue not necessarily a bug... But...

Since the system.jobId contains a GUID that is not present in job api endpoint, the only unique identifier is the JOB name.
(and MAYBE the runner name if status == in progress )

The issue becomes apparent when you apply a matrix or reusable workflow:
Note the code that handles job length....
So even while we can compile the full absolute job name the api truncates it... ie:
"build-with-reusable-workflow-with-matrix-inputs (1.1, In_this_input_we_are_testing_very_very_very... / build"
from:
API: https://api.github.com/repos/c3charvat/actions--context/actions/runs/11445449487/jobs
JOB URL: https://github.com/c3charvat/actions--context/actions/runs/11445449487/job/31842529999
Job # 2 Job actions/runner#3 which are unique but truncated to not be unique.

(Since the is the only guaranteed data shared between the job level api and the github.job context)
You cant really guarantee that you can resolve a individual jobs url.

Something similar was added for the Telemetry.
actions/runner@3d34a3c#diff-4085092f16aac893358021b20c7a92b02a504a1a99830bc88454ae0380638c45

[daleyjem]

@c3charvat I'm sure there's probably something obvious that I'm missing here, and forgive me for saying... but all of that information didn't give me a more clear path in answering whether this is something you believe I'm capable of fixing in this action. Can I ask again for just a bare bones reproduction of the issue you're having with my action specifically? I didn't see it referenced in the workflow runs you linked.

Personally, I'd rather not put in any logic in this action that "guesses", rather let the consumer of the action decide how to build out the name to match on, if truncation is the issue.

Consider this...
If your matrix logic appends a counter to the end like so:

• build-with-reusable-workflow-with-matrix-inputs (In_this_input_we_are_testing_very_very_very_very_long_string---1)
• build-with-reusable-workflow-with-matrix-inputs (In_this_input_we_are_testing_very_very_very_very_long_string---2)

...and they both become:

• build-with-reusable-workflow-with-matrix-inputs (In_this_input_we_are_testing_very_very...
• build-with-reusable-workflow-with-matrix-inputs (In_this_input_we_are_testing_very_very...

...how would I know which of those to choose from?