Build init logs doesn't print hostname if there is an initialization errror

[jithine]

What happened:

After changes in screwdriver-cd/executor-k8s#186 Build hostname is not displayed, if launcher is not able to run. This scenario can happen if build init fails.

We were updating launcher from v6.0.182 to v6.0.198

What you expected to happen:

Build init logs should always show the hostname where the build was scheduled.

How to reproduce it:

[github-actions]

Similar issues

1. 39% Inability to "Start Pipeline from Here" for some jobs using Detached #3053
2. 37% Allow a stage to declared as an upstream for a job outside of that stage #3026
3. 33% Feature request: Users want to debug screwdriver.cd/dockerEnabled: true builds by using sd-local #2969
4. 32% Dropdown menu does not appear even if the pipeline has build parameters #3082
5. 32% Ability to distinguish implicitly vs explicitly created setup or teardown for a stage #3022
6. 32% The part of the job name on the far left in workflow is not displayed. #2924
7. 30% Mark a step yellow if meta build warning is set from it #3067

_{🤖 By issues-similarity-analysis}

[jithine]

We should discuss the approach from #2882

[VonnyJap]

I wonder if there is still a chance that the build node information is missing even after the revert, in the case of no resource is available at the first update and hence is not displayed in the UI and the launcher fails to run in init step hence not updating the build stats with node name.

But I believe when a build is pending now, it will be automatically put to retry queue on this? But how many attempts to retry happens until the build has a resource to be scheduled on?
https://github.com/screwdriver-cd/buildcluster-queue-worker/blob/c6086f39ca196f89ecd38d46eb48f344eb8adf14/receiver.js#L110-L113

And in addition to that, the build status is not updated in here
https://github.com/screwdriver-cd/executor-k8s/blob/9c72331ee8e70622d174cdb6eb4993b4059c7a15/index.js#L723-L773

[VonnyJap]

@yk634 - I created a draft PR to implement your suggestion here. Can you please take a look if it makes sense? If not then, please suggest changes according to what you proposed initially.

[yk634]

@VonnyJap
It's been so long since I was looking into this that my memory isn't quite sure...

If the verify method is executed when the pod is not started due to lack of resources, I am not sure if it is possible to get the value from the spec.nodeName.

If it is possible to get the value, I think the PR fix is fine.

I was thinking of the idea of having the executor-k8s verify rerun as a retry queue even in the case of insufficient resources, assuming that the value cannot be retrieved.
(Currently, I don't think insufficient resources are reexecuted as a retry queue.)