/test

For my own understanding does that means that for the 2 and 3 commits we want to do something different for mcs-api or it means that other similar workflow (like the gw-api one) should ideally be changed too?

As for schedule vs push, I admit that we are not particularly consistent. There are a bunch of workflows that are only run on schedule (e.g., conformance l3-l4 and l7), a few only on push to main (e.g., conformance clustermesh), while the gateway API one on both apparently 😁.

AFAIK, the main rationale for triggering them on push was to get more frequent feedback to spot possible issues early. However, there are also a bunch of downsides in hindsight, including the fact that the number of runs depends on how may PRs get merged (which means that statistics are more difficult to extract, and it may have the opposite effect of being triggered very rarely during quiet periods of the year), it is inconsistent with stable branches (that are additionally triggered on schedule anyways), and requires adaptations when branching a new stable branch (i.e., the branch name in the push trigger). IMO it would be good to migrate the vast majority of workflows to schedule for consistency, but it is mostly a personal opinion (I haven't changed the other clustermesh ones here as that would need to be backported as well, but that's on my TODO list).

As for the third commit, yeah, that may be changed for the Gateway API one as well, I'm honestly not sure why it is explicitly listed there given that it is also included as part of the main /test trigger.