No, I’ve discussed this several times with y’all.
If I have an on-merge workflow for merges into main that say, take an hour each run and cost resources. Why would I want to wait for each workflow to complete for each patch in a 5+ patch stack? It could take an entire workday to get the last patch in which would slow down the velocity of my team.
Our preferred workflow is one feature is comprised of many small patches so this is a waste of time and money.
Merging from leaf down to trunk only runs the on-pull workflows because those are merges into non-main branches which are significantly shortly and less expensive. Even better, The on-pull workflows already run against the leaf so you know you can merge them down to the branch just before main and get the same results. My company does that manually for most of our repos at this time, manually fold patch/branches together and then do a final merge into main.
This would be a significant improvement for customers that are deploying production resources from GitHub workflows.