When a single job gets rerun, where do the other jobs listed come from?

[clee2000]

Select Topic Area

Question

Body

Let's say you have a workflow with 3 jobs. For some reason, you want to rerun only one of the jobs. When you click on the second run attempt, it will show runs of the other 2 jobs, while the one you rerun is pending/in progress. Where do the 2 not rerun jobs come from? I assume it's a copy of the previous run attempts since they have the same logs but a different job id. Is there a way to get a mapping from the original job id to the new one?

[Rishit-katiyar]

hi, i might be able to help you with this problem but could you please provide me with a little more information

for now , i think when you rerun a job within a workflow, the platform often creates new instances of the jobs that haven't been rerun. These instances usually inherit the parameters and settings from the original run but have different job IDs. They're essentially clones of the original jobs. As for obtaining a mapping from the original job ID to the new one, it depends on the features provided by the platform or tool you're using. Some platforms offer functionality to trace the relationship between the original job and its rerun.

[clee2000]

Hi, thanks for the help

For the platform, I'm using Github Actions, so I'm hoping for some Github API call or something, unless you're referring to a different type of platform

[Rishit-katiyar]

i am kinda shooting blindly but ...

To address the issue of unnecessary duplication of jobs within your GitHub Actions workflow, one effective approach is to strategically modify the workflow YAML file. By incorporating conditional logic directly into the workflow configuration, you can instruct the system to skip rerunning the other jobs when a specific job is triggered for rerun. This can be achieved by implementing conditional statements that check for the presence of a rerun flag or a specific event associated with the job in question. Furthermore, to enhance workflow management and efficiency, consider leveraging GitHub's powerful workflow event APIs. These APIs enable you to programmatically interact with workflow runs and their associated instances, providing granular control and automation capabilities. By utilizing the event APIs, you can precisely orchestrate job reruns, monitor workflow progress, and optimize resource utilization, ultimately ensuring smoother and more streamlined workflow execution.

[clee2000]

Hm this doesn't seem very relevant, to the best of my knowledge, none of the Github APIs interact with workflow reruns like that. I'll go check but I think a job might still show up even if you say to skip it using the run_attempt info in the github context

I don't mind the duplication/cloning of the jobs, I just want to know how to map the clones back to the originals

[Rishit-katiyar]

I will also look into it; it might help me learn more about it. if you find the fix do let me know too ,thanks