How does GitLab's pipeline trigger distinction compare to GitHub Actions' push vs pull_request trigger?

The two are conceptually similar — one trigger type reacts to a raw branch commit, the other reacts specifically to the existence of an open merge/pull request — but GitHub Actions' pull_request trigger by default already tests the merge commit of the PR against its base branch (similar to GitLab's merged results pipelines specifically, not just its plain merge request pipelines), while GitLab's plain merge request pipeline (without merged-results enabled) only tests the source branch's own commit, closer to GitHub's push behavior — meaning the "safer default" behavior sits in different places between the two platforms' equivalent trigger types.

GitHub Actions: on: push triggers a workflow run against the pushed commit directly, on whatever branch was pushed — no merge simulation at all. on: pull_request triggers a workflow run that, by default, checks out a merge commit GitHub constructs internally (the PR's source merged into its base branch) — meaning GitHub Actions' pull_request trigger is, by default, already testing the integration state, not just the source branch's isolated commit. This is closer to GitLab's merged results pipeline behavior than to GitLab's plain merge request pipeline.

GitLab CI/CD: a push-triggered (branch) pipeline tests the branch's own commit in isolation, similar to GitHub's push trigger. A merge-request-triggered pipeline, without merged results enabled, still only tests the source branch's own commit — it gets merge-request-specific context (variables, and the ability to require it for merge) but doesn't test the actual merged state by default. Merged results must be explicitly enabled to get GitLab's equivalent of GitHub's default pull_request merge-commit-testing behavior.

This means the "does this test the actual merge, or just the isolated branch" question defaults differently between the two platforms: GitHub Actions' pull_request trigger defaults to merge-commit testing; GitLab's merge request pipeline defaults to source-branch-only testing unless merged results is explicitly turned on. A team moving between the two platforms (or maintaining pipelines on both) needs to be aware of this default difference specifically, since assuming GitLab's merge request pipeline behaves like GitHub's pull_request trigger by default would be an incorrect assumption about what's actually being tested.

Both platforms share the underlying duplicate-trigger problem discussed earlier (a push and its associated PR/MR can both fire a pipeline for the same commit) and both have their own mechanism to prevent it — GitHub Actions typically handles this via concurrency: groups or careful trigger paths/conditions, GitLab via the workflow: rules: pattern with $CI_PIPELINE_SOURCE.

• GitHub Actions' pull_request trigger tests a constructed merge commit by default, closer to GitLab's merged results pipelines than to GitLab's plain merge request pipelines.
• GitLab's merge request pipeline, without merged results explicitly enabled, only tests the source branch's own commit — closer to GitHub's plain push behavior in that specific respect.
• The "tests the actual merge by default" behavior sits in different places between the two platforms, which matters when moving between them or maintaining both.
• Both platforms share the duplicate-pipeline-for-one-commit problem and solve it with their own platform-specific mechanism.

• GitLab Docs: Merged results pipelines
• GitHub Docs: Events that trigger workflows — pull_request