[9.x] Prevent workflows from running twice

[Jubeki]

Explanation

When creating a PR from a branch within the same repo (i.e. not a fork), the current run-test workflows get triggered twice - for both push and pull_request:

This PR adds constrains so that the workflow only runs once.
(Push Event will only be triggered on the master and *.x branch)

Sources

Idea and Changes are taken from spatie/package-skeleton-laravel#119
Thanks and Credits to @jessarcher

Branch names can use patterns for Pull Requests:
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet

Side note

I think it would be good to change the default branch to main per
https://github.com/github/renaming#new-repositories-use-main-as-the-default-branch-name

[GrahamCampbell]

I think that's actually desirable that they run twice, allowing testing before cutting a PR.

[Jubeki]

I think that's actually desirable that they run twice, allowing testing before cutting a PR.

I am sorry, but could you please explain what you mean with "cutting a PR"? 😅

[GrahamCampbell]

Opening a pull request.

[garygreen]

It would be better to only listen on pull_request because by default it should trigger whenever any changes occur to a pull request because it has the default types of opened synchronize and reopened:

By default, a workflow only runs when a pull_request event's activity type is opened, synchronize, or reopened. To trigger workflows by different activity types, use the types keyword

[garygreen]

Related discussions:

open-telemetry/opentelemetry-python#1370
open-telemetry/opentelemetry-python#1370 (comment)
https://stackoverflow.com/questions/70145104/github-actions-running-twice-on-merge-of-pr

[driesvints]

Bit torn. I've thought about this a lot in the past already and my gut feeling says it'll be annoying to not be able to build on individual branches anymore before sending in a PR.

It would be better to only listen on pull_request because by default it should trigger whenever any changes occur to a pull request because it has the default types of opened synchronize and reopened:

That would mean directly pushed code to existing stable branches isn't tested anymore?

[driesvints]

@Jubeki @GrahamCampbell @taylorotwell maybe we should just give this a try to see how it goes and then evaluate if we want to keep or ditch it.

[Jubeki]

Bit torn. I've thought about this a lot in the past already and my gut feeling says it'll be annoying to not be able to build on individual branches anymore before sending in a PR.

I am also a bit torn about it, but most features are worked on in a Draft PR, so that would mean the tests would still run.
(My main reasons are that it is annoying to see always two tests, double the run time and for environmental reasons)

It would be better to only listen on pull_request because by default it should trigger whenever any changes occur to a pull request because it has the default types of opened synchronize and reopened:

That would mean directly pushed code to existing stable branches isn't tested anymore?

I also think that would be the case, but I am not completely sure.

[driesvints]

Thanks @Jubeki