tembo-io / trunk Goto Github PK

When a user publishes an extension, we should:

• Ensure the API token exists and has an associated user ID
• If the extension is new, assign the associated user ID as the author
• If the extension exists, ensure the associated user ID matches the author of the extension

_{From SyncLinear.com | COR-717}

_COR-776

Users should be able to request their extension version be removed.

_{From SyncLinear.com | COR-825}

Trunk CLI should use a trunk.toml file to store extension metadata. This will hold information currently passed as flags. Example:

[extension]
name = "my_extension"
version = "0.0.0"
description = "2021"
documentation = "documentation.my_extension.com"
repository = "github.com/my_extension"
license = "PostgreSQL"
homepage = "my_extension.com"
postgres_version = "15"
architecture = "x86_64"

_{From SyncLinear.com | COR-838}

trunk build output does not include manifest.json file. This file is required for trunk install. Outup file structure should look like:

❯ tar -tvf pgmq-0.2.1.tar.gz
-rw-rw-r-- ian/ian         279 2023-03-17 06:56 manifest.json
-rw-r--r-- ian/ian        2962 2023-03-16 14:25 pgmq--0.2.1.sql
-rwxr-xr-x ian/ian     2275640 2023-03-16 14:25 pgmq.so
-rw-r--r-- ian/ian         159 2023-03-16 14:25 pgmq.control

Set up Slack organization and channel for Trunk related support and community discussion.

_{From SyncLinear.com | COR-867}

Trunk CLI should be configurable via environment variables. Here are some examples from cargo https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates.

_{From SyncLinear.com | COR-843}

Users should be able to search available extensions in the Trunk Registry with a command like trunk search <extension_name>.

_{From SyncLinear.com | COR-845}

Use orange theme to match pgtrunk.io

_{From SyncLinear.com | COR-781}

Returns all extensions in the registry. This is currently listing all files in the S3 bucket. This should instead return information from the registry's database.

_{From SyncLinear.com | COR-452}

_{From SyncLinear.com | COR-452}

Extension owners should have the ability to invite additional owners of the extension via Trunk Registry.

_{From SyncLinear.com | COR-832}

Host the Trunk CLI in additional repositories such as:

• apt

• homebrew

• yum

• zypper

• AUR

_{From SyncLinear.com | COR-839}

_{From SyncLinear.com | COR-823}

Add blog section used for publishing blog posts related to extensions:

• Top 5 extensions…
• New extensions this week…

_{From SyncLinear.com | COR-860}

Users should be able to show installed extensions with the Trunk CLI.

_{From SyncLinear.com | COR-846}

❯ trunk build
Building from path .
Detected that we are building a pgrx extension
Detected pgrx version range =0.8.2
Using pgrx version 0.8.2
Building pgrx extension at path .
Step 1/10 : ARG PG_VERSION=15
Step 2/10 : ARG PGRX_VERSION=0.8.2
Step 3/10 : FROM quay.io/coredb/pgrx-builder:pg${PG_VERSION}-pgrx${PGRX_VERSION}
[/home/ian/.cargo/registry/src/github.com-1ecc6299db9ec823/pg-trunk-0.4.7/src/commands/containers.rs:306] &err = DockerStreamError {
    error: "unknown: Tag pg15-pgrx0.8.2 was deleted or has expired. To pull, revive via time machine",
}
thread 'main' panicked at 'error occurred: Other error: Docker stream error

Caused by:
    Docker stream error', /home/ian/.cargo/registry/src/github.com-1ecc6299db9ec823/pg-trunk-0.4.7/src/main.rs:51:6
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

We need to define a process for building and publishing PGRX-builder images. We need to support the latest version of PGRX in our builder images.

_{From SyncLinear.com | COR-775}

trunk install --list show list of currently installed packages

_COR-518

Users should be able to test their extensions via Trunk CLI with a command like trunk test. Initially, tests should cover the following:

• Test extension can be installed in a local, containerized postgres instance with trunk install
• Test extension can be enabled with CREATE EXTENSION CASCADE;
• Test we're able to run some function the extension provides (this might come later)

This will help avoid publishing extensions that do not function as expected.

_{From SyncLinear.com | COR-844}

We should be able to view the following at pgtrunk.io:

• All extensions should show category tag
• Drop down list to filter extensions by category

_{From SyncLinear.com | COR-863}

Implement a system for 'certifying' Postgres extensions. This will likely involve some spike time as we think about what makes an extension 'certified'.

_{From SyncLinear.com | COR-842}

Trunk CLI should perform some sort of validation before publishing. For example, includes all necessary files and metadata.

_{From SyncLinear.com | COR-834}

Create a route that returns version history for a given extension:

• /extensions/detail/{extension_name}/

• array of versions for a given extension

  [
    {
      "createdAt": "2023-04-20 4:29:18.52241 +00:00:00",
      "description": "My incredible extension",
      "documentation": null,
      "homepage": "coredb.io",
      "version": "0.0.2",
      "license": "Apache-2.0",
      "name": "pgmq",
      "owners": [
        {
          "userId": "user_2PXTvcubP95TyEvTXZJOpzHjdJn",
          "userName": "coredb-service-user"
        }
      ],
      "repository": "https://github.com/CoreDB-io/coredb",
      "updatedAt": "2023-04-20 23:41:39.467896 +00:00:00"
      "publisher": "dummy"
    },
    {
      "createdAt": "2023-04-19 4:29:18.52241 +00:00:00",
      "description": "My incredible extension",
      "documentation": null,
      "homepage": "coredb.io",
      "version": "0.0.0",
      "license": "Apache-2.0",
      "name": "pgmq",
      "owners": [],
      "repository": "https://github.com/CoreDB-io/coredb",
      "updatedAt": "2023-04-20 22:41:39.467896 +00:00:00"
      "publisher": "dummy"
    },
    {
      "createdAt": "2023-04-18 4:29:18.52241 +00:00:00",
      "description": "My incredible extension",
      "documentation": null,
      "homepage": "coredb.io",
      "version": "0.0.0",
      "license": "Apache-2.0",
      "name": "pgmq",
      "owners": [],
      "repository": "https://github.com/CoreDB-io/coredb",
      "updatedAt": "2023-04-20 21:41:39.467896 +00:00:00"
      "publisher": "anotherdummy"
    },
  ]
  

_{From SyncLinear.com | COR-772}

Research the possibility of hosting a 'build farm' that compiles extensions on behalf of the user.

_{From SyncLinear.com | COR-840}

Trunk CLI should have the ability to update extensions to the latest version in the Trunk Registry.

_{From SyncLinear.com | COR-835}

Trunk CLI should have the ability to uninstall extensions from a Postgres server.

_{From SyncLinear.com | COR-836}

https://www.docs.pgtrunk.io/ should redirect to our GitHub Pages docs site https://coredb-io.github.io/trunk/.

Fix navigation to make it seamless to go back and forth

_{From SyncLinear.com | TEM-785}

Let's instrument cli to track events, so that we can show usage metrics on the web page for each extension

Trunk currently supports building and publishing extensions for Postgres 15. It should support a wider range of Postgres versions.

_{From SyncLinear.com | COR-826}

API for programatic interaction with the extension storage layer

Actions that the UI needs to perform:

• List extensions
• Search extensions
• Get/download extensions
• Publish extension source/binary dist

Users should be able to show installed extensions with the Trunk CLI.

_{From SyncLinear.com | COR-846}

Include extension size in metadata. This should fill in the missing value for extensions that have already been published.

_{From SyncLinear.com | COR-756}

If an extension version exists, we should not allow users to re-publish the extension.

_{From SyncLinear.com | COR-676}

Add integration tests for publish, download, and all other registry routes.

_{From SyncLinear.com | COR-831}

Extension owners can label their extensions with a configurable set of labels. This might indicate the state of development for the extension. For example, alpha or beta.

_{From SyncLinear.com | COR-883}

Extension publications in Trunk Registry should include a download count for users to view.

_{From SyncLinear.com | COR-830}

trunk uninstall <package> would be a great added feature

_COR-519

When user's sign up, automatically send a 'Welcome!' email. We can use this to determine how users heard about Trunk, what extensions they'd love to see in the registry, etc.

_{From SyncLinear.com | COR-861}

Installing some extensions requires modification to shared_preload_libraries. Trunk should automatically take care of this step for us when necessary.

_{From SyncLinear.com | COR-833}

We support building extensions for multiple system architectures. We need to specify the build architecture for each extension publication. For example, users should be able to see what architecture an extension version has been built for.

Example from Docker Hub:

_{From SyncLinear.com | COR-828}

For a given extension, users should be able to view a list of published versions. Example:

_{From SyncLinear.com | COR-681}

The goal is to create and design a database used to support a postgreSQL extension directory. Conceptually-speaking, this would be a postgreSQL equivalent to npmjs.org (JavaScript), pypi.org (Python), and crates.io (Rust).

This would be a backend storage, to which source and built binary distributions would be published and indexed.

• Where will the packages be physically stored?
• How to best organize metadata (e.g., author(s), versions)
• Defined steps to publish extensions

We currently host Trunk CLI at https://crates.io/crates/pg-trunk. We realize that not all Postgres users are Rust users. For the alpha milestone, we should host Trunk CLI in an apt repository. We'll eventually host the CLI in additional repositories such as homebrew, yum, zypper, etc.

_{From SyncLinear.com | COR-672}

Trunk CLI should allow for installing multiple extensions in one command. Example:

trunk install pgmq my_extension pg_stat_statements

_{From SyncLinear.com | COR-837}

Investigate the possibility of installing trunk extensions to remote Postgres servers.

_{From SyncLinear.com | COR-847}

Extension pages should be populated with useful information from GitHub, such as:

• README
• Version history / releases

_{From SyncLinear.com | COR-865}

Extensions published to trunk registry should be categorized. Examples include:

• indexing
• machine learning
• CDC (change data capture)
• scheduler
• search
• security
• queries
• caching
• configuration

_{From SyncLinear.com | COR-829}

Users should be able to claim ownership of extensions that we've published. We need a way to verify they are the rightful owner.

_{From SyncLinear.com | COR-866}

There is currently no metadata field for 'postgres version' in extension publications. In order to support a wider range of Postgres versions, extension publications need to be tied to a specific version of Postgres.

_{From SyncLinear.com | COR-827}

Implement an extension security scanning tool, similar to what Trivy provides.

_{From SyncLinear.com | COR-841}

Collect metrics from API (based on CLI usage, trunk install pgmq for example)

Improve telemetry and usage metrics collection so we can highlight information like:

• Top 10 most popular extensions
• What extensions might be used together
• Most popular extension categories

_{From SyncLinear.com | COR-882}