search

daleyjem / gh-job-id

NodeJS-contained action for getting the jobId from a Github workflow job run
MIT License
1 stars 0 forks source link

[Bug] Does not work in reusable workflows #5

Open qoomon opened 4 months ago

qoomon commented 4 months ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

qoomon commented 1 month ago

Also see my PR to fix this problem in the github action runner https://github.com/actions/runner/pull/3489

jeremy-daley-kr commented 1 month ago

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 commented 1 month ago

@jeremy-daley-kr https://github.com/actions/runner/pull/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 https://github.com/actions/runner/pull/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. https://github.com/actions/runner/commit/3d34a3c6d6dfd7599e489b3c04fcf95a8a428434#diff-4085092f16aac893358021b20c7a92b02a504a1a99830bc88454ae0380638c45

daleyjem commented 1 week ago

@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:

...and they both become:

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