Closed abdulari closed 1 year ago
Hey :wave:
So to provide more context, the prepare_job
hook is triggered at the beginning of the job. Since the checkouot is a step, then it is executed within a job container running a run_script_step
. The purpose of the job container is to serve as a container in which you can exec steps. The checkout should not really be a different container. But you can customize the hook however you would like :relaxed:
prepare_job
creates a job container with required mountsrun_script_step
is issued, and the default implementation tries to exec the script within the job containerrun_container_step
hookcleanup_job
hook is triggered when the job finishesI hope this helps. The checkout will only trigger the run_script_step
because it is a step within a job.
oh wow, this is useful information.
it does makes sense that checkout
step should only trigger run_script_step
👍
it also means that we can check what the step is trying to do, and choose which container we want to run it on.
wonderful. 😄
I think we can run a few additional steps to start containers to run checkout
if we can detect them.
any suggestion/documentation on hooks/API that can help us to detect what workflow is trying to run?
we can git clone those actions in a temp directory and scan for action.yml
The runner already downloads the action that needs to be executed so you can avoid the git clone :relaxed:.
The entrypoint can inform you what type of actions is it based on the executable it needs to run (node, bash, ...), and the entrypoint argument is the directory where the action is stored. So you can distinguish between a step that is trying to execute the action (it will have a script at the path starting with
/__w/_actions
), and the job step (/__w/_temp/...
)
wonderful. I think we got all the information that we need. thanks for your time 😄
Hi. I'm creating a new package for another container runtime. I can't disclose which container runtime is due to legal reasons. we've written runner-container-hooks for that runtime, and it manages to spawn and destroy the container successfully.
the problem we're facing is when the workflow use shared-workflow. in this picture, we're using actions/checkout@v3, and the container we've spawn does not have proper application installed for this action to run. from what I understand, actions/checkout@v3 are required to run on a different container (node16).
I am expecting that runner-container-hooks will get comand=prepare_job AND command=run_script_step. But from my debugging, I only receive command=run_script_step
any advice on what I can do here? I should be able to start a secondary container if I can detect which container the shared-workflow wants to use