RunScriptStep 15 second delay caused by hash directories check

[wd-hopkins]

Hook version: 0.8.0

I am seeing on every step after upgrading to 0.8.0 a 15 second delay caused by the following:

##[debug]The hash of the directory does not match the expected value; want='8426efb82b5bbe9d29f5cd4f42236bb1caa61c50bee0fad244b819b5b2f8a7e2' got='b2e1285ff25bc9908296e418094efd881c656621c96a80f1219d8c9eb40022f2'

This is from this function in the hook: https://github.com/actions/runner-container-hooks/blob/main/packages/k8s/src/k8s/index.ts#L421

The equality check seems to rely on the command find . -not -path '*/_runner_hook_responses*' -exec stat -c '%b %n' {} \; returning directories in the same order in different images. In my case the directories are equal but their hashes are computed differently due to the different ordering in the command output.

Here is the output from each command when run manually:

Runner pod:

$ find . -not -path '*/_runner_hook_responses*' -exec stat -c '%b %n' {} \;
8 .
0 ./_github_home
0 ./_github_workflow
24 ./_github_workflow/event.json
8 ./_runner_file_commands
0 ./_runner_file_commands/add_path_7ed1a015-49e6-4ea2-b889-5c2ff174f5ec
0 ./_runner_file_commands/set_env_7ed1a015-49e6-4ea2-b889-5c2ff174f5ec
0 ./_runner_file_commands/step_summary_7ed1a015-49e6-4ea2-b889-5c2ff174f5ec
0 ./_runner_file_commands/save_state_7ed1a015-49e6-4ea2-b889-5c2ff174f5ec
0 ./_runner_file_commands/set_output_7ed1a015-49e6-4ea2-b889-5c2ff174f5ec
8 ./6e521d1e-80b7-4d0f-bb8a-77d88bd96725.sh
8 ./7528dac0-aff7-11f0-bb0f-1700e21f0be4.sh

Workflow pod using image alpine:3.18.0

find . -not -path '*/_runner_hook_responses*' -exec stat -c '%b %n' {} \;
0 .
0 ./_github_home
0 ./_github_workflow
24 ./_github_workflow/event.json
8 ./6e521d1e-80b7-4d0f-bb8a-77d88bd96725.sh
8 ./_runner_file_commands
0 ./_runner_file_commands/add_path_7ed1a015-49e6-4ea2-b889-5c2ff174f5ec
0 ./_runner_file_commands/save_state_7ed1a015-49e6-4ea2-b889-5c2ff174f5ec
0 ./_runner_file_commands/set_env_7ed1a015-49e6-4ea2-b889-5c2ff174f5ec
0 ./_runner_file_commands/set_output_7ed1a015-49e6-4ea2-b889-5c2ff174f5ec
0 ./_runner_file_commands/step_summary_7ed1a015-49e6-4ea2-b889-5c2ff174f5ec

My question is also: why does this check exist if it continues after 15 attempts and does not fail?

[zarko-a]

@wd-hopkins I'm not sure why does the check exist if it's continues after 15 attempts. I guess it tries to verify files were copied successfully on the best effort basis. If they were not your action is likely gonna fail anyway.

But you were 100% right that issue is sorting of the output of find on different distros.

I made a PR that sorts the output to get consistent hash, hopefully it gets accepted.