Skip to content

Commit

Permalink
Update documentation
Browse files Browse the repository at this point in the history
  • Loading branch information
actions-user committed Nov 24, 2024
1 parent 2f4965c commit 617a60d
Show file tree
Hide file tree
Showing 89 changed files with 9,471 additions and 15 deletions.
2 changes: 1 addition & 1 deletion index.html
Original file line number Diff line number Diff line change
Expand Up @@ -2,4 +2,4 @@
<!DOCTYPE html>
<meta charset="utf-8">
<title>Redirecting...</title>
<meta http-equiv="refresh" content="0; URL=./latest/userguides/quickstart.html">
<meta http-equiv="refresh" content="0; URL=./stable/userguides/quickstart.html">
Binary file modified latest/.doctrees/environment.pickle
Binary file not shown.
Binary file modified latest/.doctrees/methoddocs/exceptions.doctree
Binary file not shown.
Binary file modified latest/.doctrees/methoddocs/main.doctree
Binary file not shown.
Binary file modified latest/.doctrees/methoddocs/middlewares.doctree
Binary file not shown.
Binary file modified latest/.doctrees/methoddocs/runner.doctree
Binary file not shown.
Binary file modified latest/.doctrees/methoddocs/subscriptions.doctree
Binary file not shown.
Binary file modified latest/.doctrees/methoddocs/utils.doctree
Binary file not shown.
Binary file modified stable/.doctrees/commands/run.doctree
Binary file not shown.
Binary file modified stable/.doctrees/environment.pickle
Binary file not shown.
Binary file modified stable/.doctrees/methoddocs/exceptions.doctree
Binary file not shown.
Binary file modified stable/.doctrees/methoddocs/main.doctree
Binary file not shown.
Binary file modified stable/.doctrees/methoddocs/middlewares.doctree
Binary file not shown.
Binary file modified stable/.doctrees/methoddocs/runner.doctree
Binary file not shown.
Binary file modified stable/.doctrees/methoddocs/subscriptions.doctree
Binary file not shown.
Binary file modified stable/.doctrees/methoddocs/utils.doctree
Binary file not shown.
Binary file modified stable/.doctrees/userguides/deploying.doctree
Binary file not shown.
Binary file modified stable/.doctrees/userguides/development.doctree
Binary file not shown.
2 changes: 1 addition & 1 deletion stable/_sources/userguides/deploying.md.txt
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ docker push your-registry-url/project/botA:latest

TODO: The ApeWorX team has github actions definitions for building, pushing and deploying.

If you are unfamiliar with docker and container registries, you can use the \[\[github-action\]\].
If you are unfamiliar with docker and container registries, you can use the \[[github-action]\].

You do not need to build using this command if you use the github action, but it is there to help you if you are having problems figuring out how to build and run your bot images on the cluster successfully.

Expand Down
10 changes: 5 additions & 5 deletions stable/_sources/userguides/development.md.txt
Original file line number Diff line number Diff line change
Expand Up @@ -141,13 +141,13 @@ def handle_on_worker_shutdown(state):

This function comes a parameter `state` that you can use for storing the results of your startup computation or resources that you have provisioned.

It's import to note that this is useful for ensuring that your workers (of which there can be multiple) have the resources necessary to properly handle any updates you want to make in your handler functions, such as connecting to the Telegram API, an SQL or NoSQL database connection, or something else. **This function will run on every worker process**.
It's import to note that this is useful for ensuring that your workers (of which there can be multiple) have the resources necessary to properly handle any updates you want to make in your handler functions, such as connecting to the Telegram API, an SQL or NoSQL database connection, or something else. **This function will run on every worker process**.

*New in 0.2.0*: These events moved from `on_startup()` and `on_shutdown()` for clarity.

#### Worker State

The `state` variable is also useful as this can be made available to each handler method so other stateful quantities can be maintained for other uses. Each distributed worker has its own instance of state.
The `state` variable is also useful as this can be made available to each handler method so other stateful quantities can be maintained for other uses. Each distributed worker has its own instance of state.

To access the state from a handler, you must annotate `context` as a dependency like so:

Expand All @@ -163,7 +163,7 @@ def block_handler(block, context: Annotated[Context, TaskiqDepends()]):

### Bot Events

You can also add an bot startup and shutdown handler that will be **executed once upon every bot startup**. This may be useful for things like processing historical events since the bot was shutdown or other one-time actions to perform at startup.
You can also add an bot startup and shutdown handler that will be **executed once upon every bot startup**. This may be useful for things like processing historical events since the bot was shutdown or other one-time actions to perform at startup.

```py
@bot.on_startup()
Expand All @@ -180,7 +180,7 @@ def handle_on_shutdown():
...
```

*Changed in 0.2.0*: The behavior of the `@bot.on_startup()` decorator and handler signature have changed. It is now executed only once upon bot startup and worker events have moved on `@bot.on_worker_startup()`.
*Changed in 0.2.0*: The behavior of the `@bot.on_startup()` decorator and handler signature have changed. It is now executed only once upon bot startup and worker events have moved on `@bot.on_worker_startup()`.

## Bot State

Expand Down Expand Up @@ -271,7 +271,7 @@ Use segregated keys and limit your risk by controlling the amount of funds that
Using only the `silverback run ...` command in a default configuration executes everything in one process and the job queue is completely in-memory with a shared state.
In some high volume environments, you may want to deploy your Silverback bot in a distributed configuration using multiple processes to handle the messages at a higher rate.

The primary components are the client and workers. The client handles Silverback events (blocks and contract event logs) and creates jobs for the workers to process in an asynchronous manner.
The primary components are the client and workers. The client handles Silverback events (blocks and contract event logs) and creates jobs for the workers to process in an asynchronous manner.

For this to work, you must configure a [TaskIQ broker](https://taskiq-python.github.io/guide/architecture-overview.html#broker) capable of distributed processing.
Additonally, it is highly suggested you should also configure a [TaskIQ result backend](https://taskiq-python.github.io/guide/architecture-overview.html#result-backend) in order to process and store the results of executing tasks.
Expand Down
4 changes: 2 additions & 2 deletions stable/commands/run.html
Original file line number Diff line number Diff line change
Expand Up @@ -142,7 +142,7 @@ <h2>silverback run<a class="headerlink" href="#silverback-run" title="Link to th
<dd><p>Override the default network and provider. (see <cite>ape networks list</cite> for options)</p>
<dl class="field-list simple">
<dt class="field-odd">Options<span class="colon">:</span></dt>
<dd class="field-odd"><p>:mainnet:node | ethereum:mainnet:node | :mainnet | ethereum:mainnet | :sepolia:node | ethereum:sepolia:node | :sepolia | ethereum:sepolia | :holesky:node | ethereum:holesky:node | :holesky | ethereum:holesky | ::node | :local:node | ethereum::node | ethereum:local:node | ::test | :local:test | ethereum::test | ethereum:local:test | :local | ethereum:local | ethereum</p>
<dd class="field-odd"><p>:goerli:node | ethereum:goerli:node | :goerli | ethereum:goerli | :mainnet:node | ethereum:mainnet:node | :mainnet | ethereum:mainnet | :sepolia:node | ethereum:sepolia:node | :sepolia | ethereum:sepolia | :holesky:node | ethereum:holesky:node | :holesky | ethereum:holesky | ::node | :local:node | ethereum::node | ethereum:local:node | ::test | :local:test | ethereum::test | ethereum:local:test | :local | ethereum:local | ethereum</p>
</dd>
</dl>
</dd></dl>
Expand Down Expand Up @@ -196,7 +196,7 @@ <h2>silverback worker<a class="headerlink" href="#silverback-worker" title="Link
<dd><p>Override the default network and provider. (see <cite>ape networks list</cite> for options)</p>
<dl class="field-list simple">
<dt class="field-odd">Options<span class="colon">:</span></dt>
<dd class="field-odd"><p>:mainnet:node | ethereum:mainnet:node | :mainnet | ethereum:mainnet | :sepolia:node | ethereum:sepolia:node | :sepolia | ethereum:sepolia | :holesky:node | ethereum:holesky:node | :holesky | ethereum:holesky | ::node | :local:node | ethereum::node | ethereum:local:node | ::test | :local:test | ethereum::test | ethereum:local:test | :local | ethereum:local | ethereum</p>
<dd class="field-odd"><p>:goerli:node | ethereum:goerli:node | :goerli | ethereum:goerli | :mainnet:node | ethereum:mainnet:node | :mainnet | ethereum:mainnet | :sepolia:node | ethereum:sepolia:node | :sepolia | ethereum:sepolia | :holesky:node | ethereum:holesky:node | :holesky | ethereum:holesky | ::node | :local:node | ethereum::node | ethereum:local:node | ::test | :local:test | ethereum::test | ethereum:local:test | :local | ethereum:local | ethereum</p>
</dd>
</dl>
</dd></dl>
Expand Down
2 changes: 1 addition & 1 deletion stable/searchindex.js

Large diffs are not rendered by default.

10 changes: 5 additions & 5 deletions stable/userguides/development.html
Original file line number Diff line number Diff line change
Expand Up @@ -258,11 +258,11 @@ <h3>Worker Events<a class="headerlink" href="#worker-events" title="Link to this
</span></pre></div>
</div>
<p>This function comes a parameter <code class="docutils literal notranslate"><span class="pre">state</span></code> that you can use for storing the results of your startup computation or resources that you have provisioned.</p>
<p>It’s import to note that this is useful for ensuring that your workers (of which there can be multiple) have the resources necessary to properly handle any updates you want to make in your handler functions, such as connecting to the Telegram API, an SQL or NoSQL database connection, or something else. <strong>This function will run on every worker process</strong>.</p>
<p>It’s import to note that this is useful for ensuring that your workers (of which there can be multiple) have the resources necessary to properly handle any updates you want to make in your handler functions, such as connecting to the Telegram API, an SQL or NoSQL database connection, or something else. <strong>This function will run on every worker process</strong>.</p>
<p><em>New in 0.2.0</em>: These events moved from <code class="docutils literal notranslate"><span class="pre">on_startup()</span></code> and <code class="docutils literal notranslate"><span class="pre">on_shutdown()</span></code> for clarity.</p>
<section id="worker-state">
<h4>Worker State<a class="headerlink" href="#worker-state" title="Link to this heading"></a></h4>
<p>The <code class="docutils literal notranslate"><span class="pre">state</span></code> variable is also useful as this can be made available to each handler method so other stateful quantities can be maintained for other uses. Each distributed worker has its own instance of state.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">state</span></code> variable is also useful as this can be made available to each handler method so other stateful quantities can be maintained for other uses. Each distributed worker has its own instance of state.</p>
<p>To access the state from a handler, you must annotate <code class="docutils literal notranslate"><span class="pre">context</span></code> as a dependency like so:</p>
<div class="highlight-py notranslate"><div class="highlight"><pre><span></span><span data-line="1"><span class="kn">from</span> <span class="nn">typing</span> <span class="kn">import</span> <span class="n">Annotated</span>
</span><span data-line="2"><span class="kn">from</span> <span class="nn">taskiq</span> <span class="kn">import</span> <span class="n">Context</span><span class="p">,</span> <span class="n">TaskiqDepends</span>
Expand All @@ -277,7 +277,7 @@ <h4>Worker State<a class="headerlink" href="#worker-state" title="Link to this h
</section>
<section id="bot-events">
<h3>Bot Events<a class="headerlink" href="#bot-events" title="Link to this heading"></a></h3>
<p>You can also add an bot startup and shutdown handler that will be <strong>executed once upon every bot startup</strong>. This may be useful for things like processing historical events since the bot was shutdown or other one-time actions to perform at startup.</p>
<p>You can also add an bot startup and shutdown handler that will be <strong>executed once upon every bot startup</strong>. This may be useful for things like processing historical events since the bot was shutdown or other one-time actions to perform at startup.</p>
<div class="highlight-py notranslate"><div class="highlight"><pre><span></span><span data-line="1"><span class="nd">@bot</span><span class="o">.</span><span class="n">on_startup</span><span class="p">()</span>
</span><span data-line="2"><span class="k">def</span> <span class="nf">handle_on_startup</span><span class="p">(</span><span class="n">startup_state</span><span class="p">):</span>
</span><span data-line="3"> <span class="c1"># Process missed events, etc</span>
Expand All @@ -292,7 +292,7 @@ <h3>Bot Events<a class="headerlink" href="#bot-events" title="Link to this headi
</span><span data-line="12"> <span class="o">...</span>
</span></pre></div>
</div>
<p><em>Changed in 0.2.0</em>: The behavior of the <code class="docutils literal notranslate"><span class="pre">&#64;bot.on_startup()</span></code> decorator and handler signature have changed. It is now executed only once upon bot startup and worker events have moved on <code class="docutils literal notranslate"><span class="pre">&#64;bot.on_worker_startup()</span></code>.</p>
<p><em>Changed in 0.2.0</em>: The behavior of the <code class="docutils literal notranslate"><span class="pre">&#64;bot.on_startup()</span></code> decorator and handler signature have changed. It is now executed only once upon bot startup and worker events have moved on <code class="docutils literal notranslate"><span class="pre">&#64;bot.on_worker_startup()</span></code>.</p>
</section>
</section>
<section id="bot-state">
Expand Down Expand Up @@ -377,7 +377,7 @@ <h2>Running your Bot<a class="headerlink" href="#running-your-bot" title="Link t
<h3>Distributed Execution<a class="headerlink" href="#distributed-execution" title="Link to this heading"></a></h3>
<p>Using only the <code class="docutils literal notranslate"><span class="pre">silverback</span> <span class="pre">run</span> <span class="pre">...</span></code> command in a default configuration executes everything in one process and the job queue is completely in-memory with a shared state.
In some high volume environments, you may want to deploy your Silverback bot in a distributed configuration using multiple processes to handle the messages at a higher rate.</p>
<p>The primary components are the client and workers. The client handles Silverback events (blocks and contract event logs) and creates jobs for the workers to process in an asynchronous manner.</p>
<p>The primary components are the client and workers. The client handles Silverback events (blocks and contract event logs) and creates jobs for the workers to process in an asynchronous manner.</p>
<p>For this to work, you must configure a <a class="reference external" href="https://taskiq-python.github.io/guide/architecture-overview.html#broker">TaskIQ broker</a> capable of distributed processing.
Additonally, it is highly suggested you should also configure a <a class="reference external" href="https://taskiq-python.github.io/guide/architecture-overview.html#result-backend">TaskIQ result backend</a> in order to process and store the results of executing tasks.</p>
<div class="admonition note">
Expand Down
4 changes: 4 additions & 0 deletions v0.6.5/.buildinfo
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
# Sphinx build info version 1
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
config: b46fa637138fb600b9e344a8377fd2af
tags: 645f666f9bcd5a90fca523b33c5a78b7
Binary file added v0.6.5/.doctrees/commands/cluster.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/commands/run.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/environment.pickle
Binary file not shown.
Binary file added v0.6.5/.doctrees/index.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/methoddocs/exceptions.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/methoddocs/main.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/methoddocs/middlewares.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/methoddocs/runner.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/methoddocs/subscriptions.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/methoddocs/utils.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/userguides/deploying.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/userguides/development.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/userguides/managing.doctree
Binary file not shown.
Binary file added v0.6.5/.doctrees/userguides/quickstart.doctree
Binary file not shown.
37 changes: 37 additions & 0 deletions v0.6.5/_sources/commands/cluster.rst.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
Cloud Platform
==============
CLI commands for interacting with the Silverback Platform.

.. click:: silverback._cli:login
:prog: silverback login
:nested: none

.. click:: silverback._cli:cluster
:prog: silverback cluster
:nested: full
:commands: new, update, list, info, health

.. click:: silverback._cli:workspaces
:prog: silverback cluster workspaces
:nested: full
:commands: new, list, info, update, delete

.. click:: silverback._cli:vars
:prog: silverback cluster vars
:nested: full
:commands: new, list, info, update, remove

.. click:: silverback._cli:registry_auth
:prog: silverback cluster registry auth
:nested: full
:commands: new, list, info, update, remove

.. click:: silverback._cli:bots
:prog: silverback cluster bots
:nested: full
:commands: new, list, info, update, remove, health, start, stop, logs, errors

.. click:: silverback._cli:pay
:prog: silverback cluster pay
:nested: full
:commands: create, add-time, cancel
11 changes: 11 additions & 0 deletions v0.6.5/_sources/commands/run.rst.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
Local Development
=================
CLI commands for local development of running Silverback bots and task workers.

.. click:: silverback._cli:run
:prog: silverback run
:nested: none

.. click:: silverback._cli:worker
:prog: silverback worker
:nested: none
9 changes: 9 additions & 0 deletions v0.6.5/_sources/index.rst.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
.. dynamic-toc-tree::
:userguides:
- quickstart
- development
- managing
- deploying
:commands:
- run
- cluster
7 changes: 7 additions & 0 deletions v0.6.5/_sources/methoddocs/exceptions.md.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
# silverback.exceptions

```{eval-rst}
.. automodule:: silverback.exceptions
:members:
:show-inheritance:
```
10 changes: 10 additions & 0 deletions v0.6.5/_sources/methoddocs/main.md.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# silverback.main

The `silverback.main` module contains the high-level implementation of the the user's
Silverback application, meant to be used to expose method handlers and other functionality.

```{eval-rst}
.. automodule:: silverback.main
:members:
:show-inheritance:
```
10 changes: 10 additions & 0 deletions v0.6.5/_sources/methoddocs/middlewares.md.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# silverback.middlewares

The `silverback.middlewares` module contains middleware intended to improve the usability of
silverback as a whole, and add integrations for the silverback platform as well.

```{eval-rst}
.. automodule:: silverback.middlewares
:members:
:show-inheritance:
```
10 changes: 10 additions & 0 deletions v0.6.5/_sources/methoddocs/runner.md.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# silverback.runner

The `silverback.runner` module contains implementations for running Silverback apps in a variety
of different scenarios and trigger methods.

```{eval-rst}
.. automodule:: silverback.runner
:members:
:show-inheritance:
```
10 changes: 10 additions & 0 deletions v0.6.5/_sources/methoddocs/subscriptions.md.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
# silverback.subscriptions

The `silverback.subscriptions` module contains an implementation of a Websocket subscription queue,
used for connected to an RPC node via websockets that implements the `eth_subscribe` RPC method.

```{eval-rst}
.. automodule:: silverback.subscriptions
:members:
:show-inheritance:
```
7 changes: 7 additions & 0 deletions v0.6.5/_sources/methoddocs/utils.md.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
# silverback.utils

```{eval-rst}
.. automodule:: silverback.utils
:members:
:show-inheritance:
```
Loading

0 comments on commit 617a60d

Please sign in to comment.