add tests and create ci workflow

Author: trouze

.github/workflows/ci.yml

@@ -0,0 +1,36 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+env:
+  CARGO_TERM_COLOR: always
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: dtolnay/rust-toolchain@stable
+        with:
+          components: rustfmt, clippy
+
+      - uses: actions/cache@v4
+        with:
+          path: |
+            ~/.cargo/registry/index
+            ~/.cargo/registry/cache
+            ~/.cargo/git/db
+            target/
+          key: cargo-${{ runner.os }}-${{ hashFiles('**/Cargo.lock') }}
+          restore-keys: cargo-${{ runner.os }}-
+
+      - run: cargo fmt --check
+      - run: cargo clippy -- -D warnings
+      - run: cargo test
+      - run: cargo build

CONTRIBUTING.md

@@ -1,156 +1,105 @@
-** replace `dbt-oss-template` with your repository name in all docs
-
-
-# Contributing to `dbt-oss-template`
-
-`dbt-oss-template` is a template for open source software projects at dbt Labs.
+# Contributing to `dbtp`
 
+`dbtp` is a Rust CLI for the dbt Cloud Platform APIs.
 
 1. [About this document](#about-this-document)
 2. [Getting the code](#getting-the-code)
 3. [Setting up an environment](#setting-up-an-environment)
-4. [Running in development](#running-dbt-oss-template-in-development)
+4. [Running in development](#running-in-development)
 5. [Testing](#testing)
-6. [Debugging](#debugging)
-7. [Adding or modifying a changelog entry](#adding-or-modifying-a-changelog-entry)
-8. [Submitting a Pull Request](#submitting-a-pull-request)
-9. [Troubleshooting Tips](#troubleshooting-tips)
+6. [Adding a changelog entry](#adding-a-changelog-entry)
+7. [Submitting a Pull Request](#submitting-a-pull-request)
 
 ## About this document
 
-There are many ways to contribute to the ongoing development of `dbt-oss-template`, such as by participating in discussions and issues. We encourage you to first read our higher-level document: ["Expectations for Open Source Contributors"](https://docs.getdbt.com/docs/contributing/oss-expectations).
-
-The rest of this document serves as a more granular guide for contributing code changes to `dbt-oss-template` (this repository). It is not intended as a guide for using `dbt-oss-template`, and some pieces assume a level of familiarity with Python development (virtualenvs, `pip`, etc). Specific code snippets in this guide assume you are using macOS or Linux and are comfortable with the command line.
+There are many ways to contribute — opening issues, joining discussions, or submitting code changes. This document focuses on the latter. It assumes familiarity with Rust and the command line.
 
-If you get stuck, we're happy to help! Drop us a line in the `#dbt-oss-template-development` channel in the [dbt Community Slack](https://community.getdbt.com).
+If you get stuck, open a [GitHub Discussion](https://github.com/trouze/dbtp/discussions) or file an issue.
 
 ### Notes
 
-- **CLA:** Please note that anyone contributing code to `dbt-oss-template` must sign the [Contributor License Agreement](https://docs.getdbt.com/docs/contributor-license-agreements). If you are unable to sign the CLA, the `dbt-oss-template` maintainers will unfortunately be unable to merge any of your Pull Requests. We welcome you to participate in discussions, open issues, and comment on existing ones.
-- **Branches:** All pull requests from community contributors should target the `main` branch (default).
-- **Releases**: This repository is never released.
+- **Branches:** All pull requests should target the `main` branch.
+- **CLA:** Contributions are accepted under the [Apache-2.0](LICENSE) license.
 
 ## Getting the code
 
-### Installing git
+### Prerequisites
 
-You will need `git` in order to download and modify the source code.
+- [Rust](https://rustup.rs/) (stable toolchain)
+- `git`
 
-### External contributors
+### Fork and clone
 
-If you are not a member of the `dbt-labs` GitHub organization, you can contribute to `dbt-oss-template` by forking the `dbt-oss-template` repository. For a detailed overview on forking, check out the [GitHub docs on forking](https://help.github.com/en/articles/fork-a-repo). In short, you will need to:
+External contributors should fork the repository, then clone their fork:
 
-1. Fork the `dbt-oss-template` repository
-2. Clone your fork locally
-3. Check out a new branch for your proposed changes
-4. Push changes to your fork
-5. Open a pull request against `dbt-labs/dbt-oss-template` from your forked repository
-
-### dbt Labs contributors
+```sh
+git clone https://github.com/<your-username>/dbtp.git
+cd dbtp
+```
 
-If you are a member of the `dbt-labs` GitHub organization, you will have push access to the `dbt-oss-template` repo. Rather than forking `dbt-oss-template` to make your changes, just clone the repository, check out a new branch, and push directly to that branch.
+dbt Labs contributors can clone directly and push to a feature branch.
 
 ## Setting up an environment
 
-There are some tools that will be helpful to you in developing locally. While this is the list relevant for `dbt-oss-template` development, many of these tools are used commonly across open-source python projects.
-
-### Tools
+No additional setup is required beyond a working Rust toolchain. Install or update via:
 
-These are the tools used in `dbt-oss-template` development and testing:
-
-- [`flake8`](https://flake8.pycqa.org/en/latest/) for code linting
-- [`black`](https://github.com/psf/black) for code formatting
-- [`mypy`](https://mypy.readthedocs.io/en/stable/) for static type checking
-- [`pre-commit`](https://pre-commit.com) to easily run those checks
-- [`changie`](https://changie.dev/) to create changelog entries, without merge conflicts
-
-A deep understanding of these tools in not required to effectively contribute to `dbt-oss-template`, but we recommend checking out the attached documentation if you're interested in learning more about each one.
-
-#### Virtual environments
-
-We strongly recommend using virtual environments when developing code in `dbt-oss-template`. We recommend creating this virtualenv
-in the root of the `dbt-oss-template` repository. To create a new virtualenv, run:
 ```sh
-python3 -m venv env
-source env/bin/activate
+rustup update stable
 ```
 
-This will create and activate a new Python virtual environment.
+## Running in development
 
-## Running `dbt-oss-template` in development
-
-### Installation
-
-First make sure that you set up your `virtualenv` as described in [Setting up an environment](#setting-up-an-environment).  Also ensure you have the latest version of pip installed with `pip install --upgrade pip`. Next, install `dbt-oss-template` (and its dependencies):
+Build and run directly with `cargo`:
 
 ```sh
-git
-pre-commit install
+cargo build                        # debug build
+cargo run -- projects list         # run a command
+cargo run -- --help                # top-level help
 ```
 
-### Running `dbt-oss-template`
+Set environment variables to avoid passing flags every run:
 
-This repository is just a template and cannot be run.
+```sh
+export DBTP_TOKEN=<your-token>
+export DBTP_ACCOUNT_ID=<your-account-id>
+```
 
 ## Testing
 
-Once you're able to manually test that your code change is working as expected, it's important to run existing automated tests, as well as adding some new ones. These tests will ensure that:
-- Your code changes do not unexpectedly break other established functionality
-- Your code changes can handle all known edge cases
-- The functionality you're adding will _keep_ working in the future
+Currently there is no automated test suite — commands are tested manually against a live dbt Cloud instance with the environment variables above.
 
+When adding tests in the future, prefer unit tests for pure logic (URL construction, argument parsing, response formatting) that do not require network access.
 
-### Initial setup
-
-None needed.
-
-### Test commands
-
-No tests included.
-
-
-### Unit, Integration, Functional?
-
-Here are some general rules for adding tests:
-* unit tests (`tests/unit`) don’t need to access a database; "pure Python" tests should be written as unit tests
-* functional tests (`tests/functional`) cover anything that interacts with a database, namely adapter
-
-## Debugging
+```sh
+cargo test    # runs any tests in the repo
+```
 
-1. The logs for a `dbt run` have stack traces and other information for debugging errors (in `logs/dbt.log` in your project directory).
-2. Try using a debugger, like `ipdb`. For pytest: `--pdb --pdbcls=IPython.terminal.debugger:pdb`
-3. 
+## Code quality
 
-### Assorted development tips
-* Append `# type: ignore` to the end of a line if you need to disable `mypy` on that line.
-* Sometimes flake8 complains about lines that are actually fine, in which case you can put a comment on the line such as: # noqa or # noqa: ANNN, where ANNN is the error code that flake8 issues.
-* To collect output for `CProfile`, run dbt with the `-r` option and the name of an output file, i.e. `dbt -r dbt.cprof run`. If you just want to profile parsing, you can do: `dbt -r dbt.cprof parse`. `pip` install `snakeviz` to view the output. Run `snakeviz dbt.cprof` and output will be rendered in a browser window.
+CI enforces formatting and lints. Run these locally before pushing:
 
-## Adding or modifying a CHANGELOG Entry
+```sh
+cargo fmt --check      # check formatting (run `cargo fmt` to fix)
+cargo clippy -- -D warnings   # lints
+```
 
-We use [changie](https://changie.dev) to generate `CHANGELOG` entries. **Note:** Do not edit the `CHANGELOG.md` directly. Your modifications will be lost.
+## Adding a changelog entry
 
-Follow the steps to [install `changie`](https://changie.dev/guide/installation/) for your system.
+We use [changie](https://changie.dev) to manage the `CHANGELOG.md`. Do not edit `CHANGELOG.md` directly.
 
-Once changie is installed and your PR is created for a new feature, simply run the following command and changie will walk you through the process of creating a changelog entry:
+Install changie, then run:
 
-```shell
+```sh
 changie new
 ```
 
-Commit the file that's created and your changelog entry is complete!
-
-If you are contributing to a feature already in progress, you will modify the changie yaml file in dbt/.changes/unreleased/ related to your change. If you need help finding this file, please ask within the discussion for the pull request!
-
-You don't need to worry about which `dbt-oss-template` version your change will go into. Just create the changelog entry with `changie`, and open your PR against the `main` branch. All merged changes will be included in the next minor version of `dbt-oss-template`. The Core maintainers _may_ choose to "backport" specific changes in order to patch older minor versions. In that case, a maintainer will take care of that backport after merging your PR, before releasing the new version of `dbt-oss-template`.
+Commit the generated file in `.changes/unreleased/` alongside your PR.
 
 ## Submitting a Pull Request
 
-Code can be merged into the current development branch `main` by opening a pull request. A `dbt-oss-template` maintainer will review your PR. They may suggest code revision for style or clarity, or request that you add unit or integration test(s). These are good things! We believe that, with a little bit of help, anyone can contribute high-quality code.
-
-Automated tests run via GitHub Actions. If you're a first-time contributor, all tests (including code checks and unit tests) will require a maintainer to approve. Changes in the `dbt-oss-template` repository trigger integration tests against Postgres. dbt Labs also provides CI environments in which to test changes to other adapters, triggered by PRs in those adapters' repositories, as well as periodic maintenance checks of each adapter in concert with the latest `dbt-oss-template` code changes.
-
-Once all tests are passing and your PR has been approved, a `dbt-oss-template` maintainer will merge your changes into the active development branch. And that's it! Happy developing :tada:
+1. Create a branch off `main`.
+2. Make your changes and ensure `cargo build`, `cargo fmt --check`, and `cargo clippy -- -D warnings` all pass.
+3. Add a changelog entry with `changie new`.
+4. Open a PR against `main`. A maintainer will review and merge.
 
-## Troubleshooting Tips
-- Sometimes, the content license agreement auto-check bot doesn't find a user's entry in its roster. If you need to force a rerun, add `@cla-bot check` in a comment on the pull request.
+CI runs automatically on all PRs. Once checks pass and the PR is approved, a maintainer will merge it.

README.md

@@ -1,5 +1,9 @@
 # dbtp — dbt Cloud Platform CLI
 
+[![CI](https://github.com/trouze/dbtp/actions/workflows/ci.yml/badge.svg)](https://github.com/trouze/dbtp/actions/workflows/ci.yml)
+[![Latest Release](https://img.shields.io/github/v/release/trouze/dbtp)](https://github.com/trouze/dbtp/releases/latest)
+[![License](https://img.shields.io/badge/license-Apache--2.0-blue)](LICENSE)
+
 A fast, ergonomic command-line interface for the [dbt Cloud](https://www.getdbt.com/product/dbt-cloud) platform APIs. Manage accounts, projects, environments, jobs, and runs. Browse your dbt DAG through the Discovery API. Query metrics through the Semantic Layer. All from your terminal.
 
 ```

src/api/admin/audit_logs.rs

@@ -4,29 +4,71 @@ use serde_json::Value;
 use crate::core::error::Result;
 use crate::core::rest_client::RestClient;
 
-pub async fn list(
-    client: &RestClient,
-    params: &[(String, String)],
-) -> Result<Vec<Value>> {
+pub async fn list(client: &RestClient, params: &[(String, String)]) -> Result<Vec<Value>> {
     client.paginate_v3("audit-logs/", params, None).await
 }
 
 /// Paginate all audit log events at or after `since`, filtering client-side.
-pub async fn export_since(
-    client: &RestClient,
-    since: &DateTime<Utc>,
-) -> Result<Vec<Value>> {
+pub async fn export_since(client: &RestClient, since: &DateTime<Utc>) -> Result<Vec<Value>> {
     let events = client.paginate_v3("audit-logs/", &[], None).await?;
 
     let filtered = events
         .into_iter()
-        .filter(|e| {
-            e["created_at"]
-                .as_str()
-                .and_then(|s| s.parse::<DateTime<Utc>>().ok())
-                .map_or(true, |dt| dt >= *since)
-        })
+        .filter(|e| event_at_or_after(e, since))
         .collect();
 
     Ok(filtered)
 }
+
+/// Returns true if the event has no parseable `created_at`, or if it is >= `since`.
+fn event_at_or_after(event: &Value, since: &DateTime<Utc>) -> bool {
+    event["created_at"]
+        .as_str()
+        .and_then(|s| s.parse::<DateTime<Utc>>().ok())
+        .is_none_or(|dt| dt >= *since)
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+    use serde_json::json;
+
+    fn ts(s: &str) -> DateTime<Utc> {
+        s.parse::<DateTime<Utc>>().unwrap()
+    }
+
+    #[test]
+    fn event_after_cutoff_is_included() {
+        let since = ts("2024-01-10T00:00:00Z");
+        let event = json!({ "created_at": "2024-01-15T12:00:00Z" });
+        assert!(event_at_or_after(&event, &since));
+    }
+
+    #[test]
+    fn event_at_cutoff_is_included() {
+        let since = ts("2024-01-10T00:00:00Z");
+        let event = json!({ "created_at": "2024-01-10T00:00:00Z" });
+        assert!(event_at_or_after(&event, &since));
+    }
+
+    #[test]
+    fn event_before_cutoff_is_excluded() {
+        let since = ts("2024-01-10T00:00:00Z");
+        let event = json!({ "created_at": "2024-01-05T00:00:00Z" });
+        assert!(!event_at_or_after(&event, &since));
+    }
+
+    #[test]
+    fn event_with_no_created_at_is_included() {
+        let since = ts("2024-01-10T00:00:00Z");
+        let event = json!({ "type": "login" });
+        assert!(event_at_or_after(&event, &since));
+    }
+
+    #[test]
+    fn event_with_unparseable_created_at_is_included() {
+        let since = ts("2024-01-10T00:00:00Z");
+        let event = json!({ "created_at": "not-a-date" });
+        assert!(event_at_or_after(&event, &since));
+    }
+}

src/api/admin/environments.rs

@@ -18,11 +18,7 @@ pub async fn list(
         .await
 }
 
-pub async fn get(
-    client: &RestClient,
-    project_id: u64,
-    environment_id: u64,
-) -> Result<Value> {
+pub async fn get(client: &RestClient, project_id: u64, environment_id: u64) -> Result<Value> {
     client
         .get_v3(
             &format!("projects/{project_id}/environments/{environment_id}/"),
@@ -31,16 +27,9 @@ pub async fn get(
         .await
 }
 
-pub async fn create(
-    client: &RestClient,
-    project_id: u64,
-    body: &Value,
-) -> Result<Value> {
+pub async fn create(client: &RestClient, project_id: u64, body: &Value) -> Result<Value> {
     client
-        .post_v3(
-            &format!("projects/{project_id}/environments/"),
-            body,
-        )
+        .post_v3(&format!("projects/{project_id}/environments/"), body)
         .await
 }
 
@@ -58,11 +47,7 @@ pub async fn update(
         .await
 }
 
-pub async fn delete(
-    client: &RestClient,
-    project_id: u64,
-    environment_id: u64,
-) -> Result<Value> {
+pub async fn delete(client: &RestClient, project_id: u64, environment_id: u64) -> Result<Value> {
     client
         .delete_v3(&format!(
             "projects/{project_id}/environments/{environment_id}/"