Expected Behavior
When GitLab creates a branch that points to an existing commit, Pipelines as
Code should process the push webhook even when its commits array is empty.
For a valid branch-creation payload, the event should use the immutable after
SHA as the revision, resolve commit metadata for that exact SHA, and evaluate
PipelineRun definitions and repository-local task references from the same
source revision.
Actual Behavior
The GitLab provider rejects every push webhook whose commits array is empty:
no commits attached to this push event
GitLab can legitimately emit this shape when a new branch is created at an
existing commit. The event is discarded before repository matching, so no
PipelineRun is created for the new branch.
Steps to Reproduce the Problem
- Configure a GitLab repository with Pipelines as Code.
- Create a new branch that points to an existing commit without creating a new
commit.
- Deliver the resulting GitLab Push Hook. The relevant fields have this shape:
{
"before": "0000000000000000000000000000000000000000",
"after": "dc922f5ea0c57ef5fb1cbc0f3ea550dfe3b5786e",
"ref": "refs/heads/release-0.1",
"checkout_sha": "dc922f5ea0c57ef5fb1cbc0f3ea550dfe3b5786e",
"commits": []
}
- Observe that webhook parsing returns
no commits attached to this push event, and no PipelineRun is triggered.
Additional Info
- Reproduced on the current
main branch at
9a97ed23075b15c7fa71f6622a13428c84c1d678.
- This is not Kubernetes-version specific; the event is rejected during webhook
parsing.
- Branch deletion and unrelated empty-commit push events should continue to be
rejected. A branch creation can be identified by a non-empty
refs/heads/<branch> ref, an all-zero before SHA, and a valid non-zero
40-character hexadecimal after SHA.
- The
after SHA should be authoritative. Looking up the mutable branch name can
race with a later push and resolve metadata or PipelineRun definitions from a
different commit.
This report was prepared with assistance from OpenAI Codex (GPT-5) and was
reviewed and validated by the submitter.
Expected Behavior
When GitLab creates a branch that points to an existing commit, Pipelines as
Code should process the push webhook even when its
commitsarray is empty.For a valid branch-creation payload, the event should use the immutable
afterSHA as the revision, resolve commit metadata for that exact SHA, and evaluate
PipelineRun definitions and repository-local task references from the same
source revision.
Actual Behavior
The GitLab provider rejects every push webhook whose
commitsarray is empty:GitLab can legitimately emit this shape when a new branch is created at an
existing commit. The event is discarded before repository matching, so no
PipelineRun is created for the new branch.
Steps to Reproduce the Problem
commit.
{ "before": "0000000000000000000000000000000000000000", "after": "dc922f5ea0c57ef5fb1cbc0f3ea550dfe3b5786e", "ref": "refs/heads/release-0.1", "checkout_sha": "dc922f5ea0c57ef5fb1cbc0f3ea550dfe3b5786e", "commits": [] }no commits attached to this push event, and no PipelineRun is triggered.Additional Info
mainbranch at9a97ed23075b15c7fa71f6622a13428c84c1d678.parsing.
rejected. A branch creation can be identified by a non-empty
refs/heads/<branch>ref, an all-zerobeforeSHA, and a valid non-zero40-character hexadecimal
afterSHA.afterSHA should be authoritative. Looking up the mutable branch name canrace with a later push and resolve metadata or PipelineRun definitions from a
different commit.
This report was prepared with assistance from OpenAI Codex (GPT-5) and was
reviewed and validated by the submitter.