You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introduced a new configuration option `require-ok-to-test-sha` that
enforces the use of a commit SHA when using the `/ok-to-test` command.
This helps to mitigate race conditions where a malicious actor could
push a commit after the `/ok-to-test` comment is made but before the CI
runs.
The regular expression for parsing `/ok-to-test` comments was updated to
capture an optional SHA. New tests were added to cover various
scenarios, including valid and invalid SHAs, and the absence of a SHA
when required. The `ParsePayload` function was modified to handle this
new validation logic, and appropriate error messages were created for
cases where the SHA is missing or does not match the pull request's HEAD
SHA.
Co-authored-by: Cursor
Signed-off-by: Chmouel Boudjnah <[email protected]>
Copy file name to clipboardExpand all lines: docs/content/docs/guide/gitops_commands.md
+35Lines changed: 35 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,6 +39,41 @@ This will always trigger a new PipelineRun, even if previous runs were successfu
39
39
40
40
Similar to `/retest`, the `/ok-to-test` command will only trigger new PipelineRuns if no successful PipelineRun already exists for the same commit. This prevents duplicate runs when repository owners repeatedly test the same commit by `/test` and `/retest` command.
41
41
42
+
### Requiring a SHA with `/ok-to-test`
43
+
44
+
{{< tech_preview "Requiring a SHA argument to `/ok-to-test`" >}}
Cluster administrators can enforce SHA validation on `/ok-to-test` by setting
48
+
`require-ok-to-test-sha: "true"` in the Pipelines-as-Code ConfigMap. This
49
+
feature currently applies only to GitHub, as its `issue_comment` event does not
50
+
include the pull request’s HEAD SHA (unlike other providers that do).
51
+
52
+
Without this SHA, a small timing window exists where an attacker could push a
53
+
new commit immediately after an owner comments `/ok-to-test`, causing CI to run
54
+
on unintended code. Requiring the reviewer to include the commit ID eliminates
55
+
this risk until GitHub includes the SHA in its webhook payload.
56
+
57
+
When enabled, repository owners and collaborators must append a 7–40 character
58
+
Git SHA (in lowercase or uppercase hexadecimal) to the command, for example:
59
+
60
+
```text
61
+
/ok-to-test 1A2B3C4
62
+
```
63
+
64
+
Pipelines-as-Code verifies the provided SHA against the pull request’s current HEAD:
65
+
66
+
- Short SHAs must match the HEAD commit’s prefix.
67
+
- Full SHAs must match exactly.
68
+
69
+
If the SHA is missing or invalid, the comment is rejected, and the bot replies
70
+
with instructions to retry using the correct value. This mechanism protects
71
+
GitHub repositories from the time-of-check/time-of-use vulnerability,
72
+
a risk that other providers avoid by including the commit SHA directly in the
73
+
webhook payload.
74
+
75
+
### Targeting Specific PipelineRuns
76
+
42
77
If you have multiple `PipelineRun` and you want to target a specific `PipelineRun`, you can use the `/test` command followed by the specific PipelineRun name to restart it. Example:
0 commit comments