-
Notifications
You must be signed in to change notification settings - Fork 66
🌱 Add basic webhook support e2e #2108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🌱 Add basic webhook support e2e #2108
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
d26c5a6
to
57f0463
Compare
Signed-off-by: Per Goncalves da Silva <pegoncal@redhat.com>
Signed-off-by: Per Goncalves da Silva <pegoncal@redhat.com>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2108 +/- ##
==========================================
+ Coverage 73.55% 73.65% +0.09%
==========================================
Files 78 78
Lines 7260 7260
==========================================
+ Hits 5340 5347 +7
+ Misses 1568 1564 -4
+ Partials 352 349 -3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
/lgtm I like your idea of moving some of the shared logic in the e2e tests into a shared library in a future issue/PR. |
Look at those experimental-e2e results!
|
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: tmshort The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
5786e67
into
operator-framework:main
Description
Depends on #2107 to pass
Adds a basic webhook support e2e to the experimental e2e suite.
We should consider building a little e2e test library as there will be much re-use between the tests and the streams (standard, experimental, etc.). Alternatively, maybe we should consider not having multiple e2e test suites and use labels or some other artifice to to structure/select what gets run in which scenario. This might also make it easier to re-use helper functions and always ensure that the e2e suite is concise and consistent as features graduate.
Reviewer Checklist