Stargazers

A simple Obelisk webhook endpoint and a workflow that monitors GitHub repositories. Every step is persisted and replayed during crash recovery.

Workflow Code Example - star-added

fn star_added(login: String, repo: String) -> Result<(), String> {
    // 1. Persist the user giving a star to the project.
    let description = db::user::add_star_get_description(&login, &repo)?;
    if description.is_none() {
        // 2. Fetch the account info from GitHub.
        let info = github::account::account_info(&login)?;
        // 3. Fetch the prompt from the database.
        let settings_json = db::llm::get_settings_json()?;
        // 4. Generate the user's description.
        let description = llm::respond(&info, &settings_json)?;
        // 5. Persist the generated description.
        db::user::update_user_description(&login, &description)?;
    }
    Ok(())
}

Here is the complete workflow source and the WIT file describing the interface.

Setting up

Setting up the external services

The activities require folowing values to be present as environment variables:

export GITHUB_TOKEN_STARGAZERS="..."
export OPENAI_API_KEY="..."
export TURSO_TOKEN="..."
export GITHUB_WEBHOOK_SECRET="some-secret"
export TURSO_LOCATION="[yourdb].turso.io"

Turso activity

This activity is responsible for persistence of users and their generated descriptions.

Follow the prerequisites section of the activity-db-turso README.

GitHub activity

This activity is used to find more information about the GitHub user who starred a configured repository.

Follow the prerequisites section of the activity-github README.

OpenAI activity

Generates description based on user's repositories and organizations.

Follow the prerequisites section of the activity-llm-openai README.

Reimplementations in JavaScript and Go are available for comparison.

GitHub webhook endpoint

The webhook collects events sent by GitHub when a user stars one of the configured repositories, then triggers the workflow execution.

Follow the prerequisites section of the webhook README. Reimplementations in JavaScript and Go are available for comparison.

Workflow

Workflow orchestrates all the activities, is triggered by the webhook.

Reimplementations in JavaScript and Go are available for comparison.

Running

Set up the environment: If direnv and Nix are available:

cp .envrc-example .envrc
direnv allow

Otherwise install the following:

• Obelisk
• Optionally Rust for building the WASM components locally, version and other components are specified in rust-toolchain.toml
• Optionally Wasmtime for integration testing of activities
• Optionally Cloudflared for exposing the webhook endpoint

The exact versions of dependencies used for development and testing are in dev-deps.txt.

obelisk server run --server-config ./server.toml --deployment ./obelisk-oci.toml

The server will start downloading the WASM components from the Docker Hub. Wait for the following lines in the process output:

HTTP server `external` is listening on http://127.0.0.1:9090
HTTP server `webui` is listening on http://127.0.0.1:8080
Serving gRPC requests at 127.0.0.1:5005
Server is ready

The workflow can be started using the Web UI. The webhook endpoint can be triggered using curl or by seting up the webhook in a GitHub repo. See the webhook documentation for details on how to set up GitHub and a https tunnel to the local instance.

Building the WASM components locally

The configuration above downloads the WASM Components from the Docker Hub. To build all the Rust components locally run

just rust
obelisk server run --server-config ./server.toml --deployment ./obelisk-local.toml

JavaScript components are loaded directly by Obelisk and do not need a build step:

just js

To build Go components use

just go

Make sure to use tools and versions as specified in dev-deps.txt.