here and in other similar expressions, I find using explicit array indices into the yaml arrays error-prone. One will have to update all indices if another print task is inserted at the start, or the task order is changed.

I'd love to see some unique placeholder values being found and replaced, or at least using the search to find the task with a given name

here and in other similar expressions, I find using explicit array indices into the yaml arrays error-prone. One will have to update all indices if another print task is inserted at the start, or the task order is changed.

well that is true, but given the limitations we have with lua injected in YAMLs https://docs.ceph.com/projects/teuthology/en/latest/fragment_merging.html, I'm not sure how can we achieve this, maybe @batrick (since he wrote this code) can add throw some light here, or we can brute force this by running a loop to search for the placeholders? what do you think?

I'd love to see some unique placeholder values being found and replaced, or at least using the search to find the task with a given name

well, yes, at least you can add a lua function that searches for and replaces a string with another object. Once you have that well tested, I'd suggest that you added it to teuthology/suite/fragment-merge.lua.

Another approach that's really a PR on its own would be to allow referencing lua functions from inside the yaml values with some general syntax, roughly

value_from_lua:
   script: "evaluated + by + the + same + lua + context + as + premerge"

the latter would be handy, as the premerge could then declare a bunch of global vars that this script could reference, or call functions from the premerge script.

There is another thing we should consider, which is YAML's anchors and references. Also, there's tagging to create python objects, which we could also employ.

I understand the possibilities of improvement here, but AFAIU these changes are high prio, patrick and venky have been waiting since long to get this so that we can start testing n-1|n-2 -> main. I'm fine either way, it's your, @vshankar or @batrick's call finally. Do let me know with what approach you guys think we should move forward with, so that I can plan things out accordingly.

Another approach would be to (since the aim is to move to dynamic pulling of releases) move ahead with these changes as it is and work on #56338, where I see @leonid-s-usov 's suggestions coming in. If we're successful in having that PR work then we might not need to have the search func

I am fine with this code if we know that it's temporary and will be reverted with the solution from #56338