Added changes field in push event struct for Bitbucket server #1886
Conversation
zakisk
force-pushed
the
SRVKP-6981
branch
2 times, most recently
from
9c5d34d to
d732874
Compare
|
|
||
| type ToCommit struct { | ||
| bbv1.Commit | ||
| Parents []bbv1.Commit `json:"parents"` // bbv1.Commit also has Parents field, but its Parents has only two fields while actual payload has more. |
There was a problem hiding this comment.
is there any test testing this with dynamic variable for bitbucketserver?
There was a problem hiding this comment.
No unit test, it could have done in bitbucketserver/parse_payload_test.go but no field from this struct is referenced there as well.
There was a problem hiding this comment.
so how to make sure this works?
There was a problem hiding this comment.
I confirmed running locally
There was a problem hiding this comment.
@chmouel is there anyway to cover it in unit test because I am seeing it only referenced in dynamic variable (apart from E2E, can be covered in it)
There was a problem hiding this comment.
Can you see if you ca add one ?
|
/test |
added changes field in push event struct for Bitbucket to make it available in PipelineRun's dynamic variable https://issues.redhat.com/browse/SRVKP-6981 Signed-off-by: Zaki Shaikh <zashaikh@redhat.com>
| NumberofPRMatch: 1, | ||
| MinNumberStatus: 1, | ||
| } | ||
| wait.Succeeded(ctx, t, runcnx, opts, successOpts) |
There was a problem hiding this comment.
Failure of E2E test is obvious here because wait.Succeeded checks for EventType, but in bitbucket server EventType is not setin its ParsePayload func. PR #1891 fixes that after getting merge this E2E test will pass.
added changes field in push event struct for Bitbucket to make it available in PipelineRun's dynamic variable
https://issues.redhat.com/browse/SRVKP-6981
Changes
Submitter Checklist
📝 Ensure your commit message is clear and informative. Refer to the How to write a git commit message guide. Include the commit message in the PR body rather than linking to an external site (e.g., Jira ticket).
♽ Run make test lint before submitting a PR to avoid unnecessary CI processing. Consider installing pre-commit and running pre-commit install in the repository root for an efficient workflow.
✨ We use linters to maintain clean and consistent code. Run make lint before submitting a PR. Some linters offer a --fix mode, executable with make fix-linters (ensure markdownlint and golangci-lint are installed).
📖 Document any user-facing features or changes in behavior.
🧪 While 100% coverage isn't required, we encourage unit tests for code changes where possible.
🎁 If feasible, add an end-to-end test. See README for details.
🔎 Address any CI test flakiness before merging, or provide a valid reason to bypass it (e.g., token rate limitations).
If adding a provider feature, fill in the following details:
(update the documentation accordingly)