ci: no pipeline on pull_request - #2016

I believe we still need pull_request for other contributor, we can reduce it to build with push, pull_request, and release_test with push only.

I do not see the difference between them? If the checks has been done on the push of the branch, why redoing them after each even on the pull request? It would make sense if we would retrieve something from the PL and check it, but we do not do that

CI on pull request is there so that we can see at a glance if someone is trying to make a pull request that breaks things, like editing old release notes files in a way that breaks release note generation. CI on push catches commits that can happen via avenues other than PR, allows people to see if their commits will pass our CI before creating their pull request, and lights the badge up. Neither are considerable for removal.

Sorry but I do not agree. If you look in this PL, there is only checks on "push" event, and it does the protection like you say. It is the same jobs, executed twice so it is a waste of resource.

Before:

After:

"pull_request" only react to event on the pull requests, like comments, review, etc. There is no use here, since we do not consume anything from it in the pipeline. For exemple, in my job we use Gitlab, we do that, we actually retrieve something from the merge request API (checklist status, review even some comments in the MR,...) and we have a job that can read this information and process it and fail or not the build for instance.

For guake, we do not use it. Events on pull request does not change the commits. If there is any review and change requested, the developers will do another git push and so another "push" event is generated and so a new pipeline is started.

Reopening.

thx for approval. I merge