Getting excited :-)

Few comments:

1. The trigger should be on push, not on pull_request (so the developer can fix any found issue in follow-up push)
2. I think we want it only on release branch (at least for starters): development, 1.10.x ..
3. Optimization (worthwhile if not too hard): on push, cancel previous run on this PR, if exist

For me Point 1 should be when PR is open, else we trigger too many of those pipelines. They can open a draft PR if they want to trigger the pipeline a bit before.
Point 2 I agree 100% we are triggering it only for development, if we have a naming convention for release branches we can add them ( but we don' t, so please list branches we want to add )
Point 3 is a good idea, I can implement it on another PR

Getting excited :-)
Few comments:

1. The trigger should be on push, not on pull_request (so the developer can fix any found issue in follow-up push)
2. I think we want it only on release branch (at least for starters): development, 1.10.x ..
3. Optimization (worthwhile if not too hard): on push, cancel previous run on this PR, if exist

For me Point 1 should be when PR is open, else we trigger too many of those pipelines. They can open a draft PR if they want to trigger the pipeline a bit before. Point 2 I agree 100% we are triggering it only for development, if we have a naming convention for release branches we can add them ( but we don' t, so please list branches we want to add ) Point 3 is a good idea, I can implement it on another PR

For point-1 - that's why added more runners, so we can run on every push (stats is average of 40 push per day, max of 10 concurrent).
It will help to have point-3 as well.