Repository navigation
Conversation
Paco Review 🔍This PR adds GitHub release event support to Pipelines-as-Code. It introduces a new Review difficulty: 4/5 (Hard) — The change spans multiple layers (trigger types, provider payload parsing, custom params, webhook bootstrap, CLI, docs, and E2E tests) with non-trivial tag-resolution logic and a new YAML-marshalling approach for the release body template variable. 4 new inline comment(s) found. Reviewed commit: 98b06f5 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3041 +/- ##
==========================================
- Coverage 91.98% 91.97% -0.01%
==========================================
Files 167 167
Lines 12965 13025 +60
==========================================
+ Hits 11926 11980 +54
- Misses 1038 1044 +6
Partials 1 1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
🟡 Changes recommended
Unresolved event setup, authorization, and payload handling gaps prevent supported release workflows from running.
5 open issues
What changed in this PR
Adds GitHub release events to Pipelines-as-Code so matching PipelineRuns can execute against released tags.
Changes:
- Adds the
releasetrigger, action filtering, and tag SHA resolution. - Adds unit tests and end-to-end tests for annotated and lightweight tags.
- Documents release matching and GitHub event subscriptions.
| File | Description |
|---|---|
| test/pkg/github/tag.go | Adds release creation and deletion helpers. |
| test/github_release_test.go | Tests release pipelines for both tag types. |
| pkg/provider/github/parse_payload.go | Parses releases and resolves tag SHAs. |
| pkg/provider/github/parse_payload_test.go | Tests release payload handling. |
| pkg/provider/github/detect.go | Accepts the released action. |
| pkg/provider/github/detect_test.go | Tests release action filtering. |
| pkg/params/triggertype/types.go | Defines the release trigger. |
| docs/content/docs/providers/github-webhook.md | Adds release webhook subscription instructions. |
| docs/content/docs/providers/github-app.md | Adds release App subscription instructions. |
| docs/content/docs/guides/event-matching/cel-expressions.md | Adds release filtering examples. |
| docs/content/docs/guides/event-matching/_index.md | Documents release annotations and supported actions. |
| docs/content/docs/concepts.md | Lists release as a supported event. |
Review effort: Balanced
dbb0a3a to
7a51eee
Compare
c8d4685 to
98b06f5
Compare
|
/paco review |
theakshaypant
left a comment
There was a problem hiding this comment.
Only went through the docs so far, will do another walkthrough of the code
|
|
||
| Using block format avoids validation errors and keeps your YAML properly structured. | ||
|
|
||
| ### Using the release body |
There was a problem hiding this comment.
[question] is there a limit on the size of the release body?
There was a problem hiding this comment.
don't know but I guess there is no such limit
There was a problem hiding this comment.
Asked this as I was thinking of cases where release_body is used and is LONG, could that cause any issues with creation of the object. For reference, found this test which checks for the max length of an object.
There was a problem hiding this comment.
I don't think that anyone would add that much release notes but yeah as it's newly added feature we will see if reported we can revisit it
|
|
||
| Both annotated tags and lightweight tags are supported. Pipelines-as-Code resolves the tag to its underlying commit SHA so that the PipelineRun runs against the correct source. | ||
|
|
||
| Only the `released` action triggers a PipelineRun. Draft releases, pre-releases, and other release actions (such as `created`, `edited`, or `deleted`) do not trigger a match. |
There was a problem hiding this comment.
actually released mean when you're really making a release available for others, published can be a pre-release, or a draft release but release mean this is really released (too many releases 😄 )
There was a problem hiding this comment.
Haha, yes I understand the distinction now :P
[nit] I was suggesting explicitly add that published action as not supported even though we have draft releases, pre-releases not being supported.
5cf1cf9 to
df68e9b
Compare
Add support for GitHub release events in Pipelines-as-Code. When a GitHub release is released, the controller detects the event, resolves the tag (both annotated and lightweight) to its underlying commit SHA, and triggers matching PipelineRuns. Example PipelineRun annotation: ```yaml pipelinesascode.tekton.dev/on-event: "[release]" pipelinesascode.tekton.dev/on-target-branch: "[refs/tags/*]" ``` Changes: - Add `release` trigger type and detection for `released` action - Handle webhook client initialization for release events - Resolve annotated tags via Git ref API, lightweight tags directly - Add E2E test helpers (CreateRelease, DeleteRelease) - Add E2E tests for annotated and lightweight tag releases - Document release event matching, CEL expressions, and webhook setup Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Zaki Shaikh <zashaikh@redhat.com>
df68e9b to
e92193b
Compare
theakshaypant
left a comment
There was a problem hiding this comment.
Question (again) about the ACL for release events.
tektoncd/pipeline uses a robot account to do releases, how would a pr be triggered in such cases? Or is an account being able to publish a release = enough permissions to trigger a pr
@theakshaypant I don't think that would be an issue because E2E test is also makes the release with github app creds and its working |
|
@theakshaypant I think you're right I have found an issue with github app creds but don't whether it will be the same as with bot account |
|
@theakshaypant I had to add my github app bot username in OWNERS to run the e2e, but it's responsibility of pac deployment owner to give appropriate permissions |



📝 Description of the Change
Add support for GitHub
releaseevents in Pipelines-as-Code. When a GitHub release is released (via thereleasedaction), the controller detects the event, resolves the tag — both annotated and lightweight — to its underlying commit SHA, and triggers matching PipelineRuns.What this PR does
releaseas a newtriggertype.Triggerconstant alongsidepush,pull_request, andincoming.detectTriggerTypeFromPayloadto handle*github.ReleaseEvent. Only thereleasedaction is supported; other actions (created,edited,published,deleted, etc.) are ignored.handleReleaseEventwhich:MatchEventURLRepoIssueCommentEvent)CreateReleaseandDeleteReleasefunctions intest/pkg/github/tag.goExample PipelineRun annotation
Example CEL expression
🔗 Linked GitHub Issue
🧪 Testing Strategy
Unit tests added
detect_test.go: Tests thatreleasedaction is detected as processable, andpublishedaction is rejectedparse_payload_test.go(8 new test cases):E2E tests added
TestGithubGHEReleaseAnnotatedTag— creates a branch, pushes a.tekton/pipelinerun.yaml, creates an annotated tag with a unique name, creates a release, and waits for the PipelineRun to succeedTestGithubGHEReleaseLightweightTag— same flow with a lightweight tag🤖 AI Assistance
AI was used to help write unit tests, E2E tests, and documentation. All code has been reviewed, understood, and validated by the author.
✅ Submitter Checklist
fix:,feat:) matches the "Type of Change" I selected above.make testandmake lintlocally to check for and fix any issues. For an efficient workflow, I have considered installing pre-commit and runningpre-commit installto automate these checks.🤖 Generated with Claude Code