Ingest GitHub events directly into your RisingWave database for real-time processing and analytics.
GitHub.com
. When one of those events is triggered, GitHub sends an HTTP POST payload to the webhook’s configured URL. Webhooks can be used to update an external issue tracker, trigger CI builds, update a backup mirror, or even deploy to your production server.
This guide will walk through the steps to set up RisingWave as a destination for GitHub webhooks.
Parameter or clause | Description |
---|---|
data JSONB | Defines the name of column to store the JSON payload from the webhook. Currently, only JSONB type is supported for webhook tables. |
is_batched | Optional, set to true to enable batch ingestion of multiple JSON lines in a single request. |
SECRET <secret> | Use an existing secret to verify incoming webhook requests. This is optional. You can also use a raw string to verify. |
headers->>'...' | Extracts the signature provided by GitHub in the x-hub-signature-256 HTTP header. In secure_compare() function, the whole HTTP header is interpreted as a JSONB object, and you can access the header value using the ->> operator, but only the lower-case header names in the ->> operator, otherwise the verification will fail. |
'sha256=' || encode(...) | Computes the expected signature. In the example above, it generates an HMAC SHA-256 hash of the payload (data ) using the secret (test_secret ), encodes it in hexadecimal, and prefixes it with sha256= . |
secure_compare(...) | Validates requests by matching the header signature against the computed signature, ensuring only authenticated requests are processed. The secure_compare() function compares two strings in a fixed amount of time, regardless of whether they are equal or not, ensuring that the comparison is secure and resistant to timing attacks. |
SHA-1
and SHA-256 HMAC
algorithms for signing the payload. The example above uses SHA-256 HMAC
. If you want to use SHA-1
, change x-hub-signature-256
into x-hub-signature
, sha256
into sha1
in the VALIDATE
clause.
Or you can also use raw string for verification without secret:
https://<HOST>/webhook/<database>/<schema_name>/<table_name>
.
Parameter | Description |
---|---|
HOST | The hostname or IP address where your RisingWave instance is accessible. This could be a domain name or an IP address. |
database | The name of the RisingWave database where your table resides |
schema_name | The schema name of your table, typically public unless specified otherwise. |
table_name | The name of the table you created to receive webhook data, e.g., wbhtable . |
application/json
.'TEST_WEBHOOK'
). This ensures that GitHub signs the payloads using this secret, allowing RisingWave to validate them.data->'field_name'
in SQL queries.
You can create a materialized view to extract specific fields from the JSON payload.
github_events
like a regular table to perform analytics, generate reports, or trigger further processing.