datasecops-cli 0.1.0__tar.gz

datasecops_cli-0.1.0/.github/workflows/publish-cli.yml

@@ -0,0 +1,56 @@
+name: Publish datasecops-cli to PyPI
+
+on:
+  push:
+    tags:
+      - 'cli-v*'
+
+permissions:
+  id-token: write
+  contents: read
+
+jobs:
+  test:
+    name: Test (Python ${{ matrix.python-version }})
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        python-version: ['3.11', '3.12', '3.13']
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Set up Python ${{ matrix.python-version }}
+        uses: actions/setup-python@v5
+        with:
+          python-version: ${{ matrix.python-version }}
+
+      - name: Install package with test dependencies
+        run: pip install -e ".[test]"
+
+      - name: Run tests
+        run: pytest --tb=short
+
+  build-and-publish:
+    name: Build and publish to PyPI
+    needs: test
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: '3.11'
+
+      - name: Install build tools
+        run: pip install build
+
+      - name: Build package
+        run: python -m build
+
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@release/v1

datasecops_cli-0.1.0/.gitignore

@@ -0,0 +1,222 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#   Usually these files are written by a python script from a template
+#   before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+# Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+# uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+# poetry.lock
+# poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+# pdm.lock
+# pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+# pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# Redis
+*.rdb
+*.aof
+*.pid
+
+# RabbitMQ
+mnesia/
+rabbitmq/
+rabbitmq-data/
+
+# ActiveMQ
+activemq-data/
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#   JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#   be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#   and can be added to the global gitignore or merged into this file.  For a more nuclear
+#   option (not recommended) you can uncomment the following to ignore the entire idea folder.
+# .idea/
+
+# Abstra
+#   Abstra is an AI-powered process automation framework.
+#   Ignore directories containing user credentials, local state, and settings.
+#   Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#   Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
+#   that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#   and can be added to the global gitignore or merged into this file. However, if you prefer,
+#   you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+# Temporary file for partial code execution
+tempCodeRunnerFile.py
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml
+
+
+legacy_framework/
+plans/

datasecops_cli-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Data Engineers
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

datasecops_cli-0.1.0/PKG-INFO

@@ -0,0 +1,16 @@
+Metadata-Version: 2.4
+Name: datasecops-cli
+Version: 0.1.0
+Summary: DataSecOps Framework CLI for Snowflake Native App
+License-Expression: MIT
+License-File: LICENSE
+Requires-Python: >=3.10
+Requires-Dist: colorama>=0.4
+Requires-Dist: gitpython>=3.1
+Requires-Dist: pydantic>=2.0
+Requires-Dist: pyyaml>=6.0
+Requires-Dist: snowflake-connector-python>=3.0
+Requires-Dist: sqlfluff>=3.0
+Provides-Extra: test
+Requires-Dist: pytest-cov>=4.0; extra == 'test'
+Requires-Dist: pytest>=7.0; extra == 'test'

datasecops_cli-0.1.0/README.md

@@ -0,0 +1,191 @@
+# DataSecOps Framework CLI
+
+Command-line interface for the DataSecOps Framework Snowflake Native App. Provides interactive menus for dbt development, git source control, and downloading framework configurations locally.
+
+## Prerequisites
+
+Before running setup, ensure you have:
+
+1. **Python 3.10+** installed
+2. **A Snowflake connection** configured in `~/.snowflake/connections.toml`
+3. **The DataSecOps Framework native app** installed in your Snowflake account
+4. **A project profile** created in the native app (via the admin UI)
+
+Optional but recommended:
+
+- **dbt Fusion** (or dbt-core with dbt-snowflake) — required for dbt commands
+- **Cortex Code** — required for skill downloads
+
+## Quick Start
+
+### 1. Run the setup script
+
+The setup script checks prerequisites, creates a virtual environment, installs the CLI, and writes your local configuration.
+
+**Linux / macOS:**
+
+```bash
+chmod +x setup.sh
+./setup.sh
+```
+
+**Windows (PowerShell):**
+
+```powershell
+.\setup.ps1
+```
+
+The script will prompt you for:
+
+- **Connection name** — the name of your Snowflake connection from `~/.snowflake/connections.toml`
+- **Native app database name** — the database where the DataSecOps Framework app is installed (e.g. `DATA_ENGINEERS_DATASECOPS_FRAMEWORK`)
+
+### 2. Activate the virtual environment
+
+**Linux / macOS:**
+
+```bash
+source .venv/bin/activate
+```
+
+**Windows:**
+
+```powershell
+.\.venv\Scripts\Activate.ps1
+```
+
+### 3. Run the CLI
+
+```bash
+datasecops
+```
+
+This connects to the native app, loads your project configuration, and presents the main menu.
+
+## What the CLI Does
+
+### Main Menu
+
+```
+[1] development   - dbt Development Commands
+[2] git           - Source Control Operations
+[3] downloads     - Download Configs & Skills
+[0] exit          - Exit
+```
+
+### Development Menu
+
+Run dbt commands via dbt Fusion:
+
+- **run** — full run, modified only (`state:modified+`), or specific models
+- **build** — run + test in one command
+- **test** — all tests or specific selectors
+- **lint** — SQLFluff lint/fix on modified files or entire project
+- **deps** — install dbt packages
+- **seed** — load seed data
+- **compile** — compile models
+- **snapshot** — run snapshots
+- **freshness** — check source freshness
+- **docs** — generate and serve dbt docs
+- **clean / debug / list / retry**
+
+### Git Menu
+
+Source control operations via GitPython:
+
+- **branching** — create, checkout, switch, delete, prune, reset
+- **commit** — stage all changes, enter message, auto-push
+- **push / pull** — sync with remote
+- **rebase** — standard rebase or squash & rebase with main
+- **deploy** — push to environment branches (dev/test/prod)
+- **squash to test** — squash merge current branch into test
+- **cherry-pick from test** — select and cherry-pick specific commits from test
+
+Branch naming follows the convention configured in the native app (e.g. `feature/123_my-feature`).
+
+### Downloads Menu
+
+Pull configurations from the native app to your local project:
+
+- **SQLFluff config** — downloads linting rules to `.sqlfluff`
+- **Pipeline files** — downloads CI/CD workflows (GitHub Actions or Azure DevOps)
+- **dbt packages** — updates `packages.yml` with versions from the framework, optionally runs `dbt deps`
+- **Cortex Code skills** — list, install, or update framework skills for Cortex Code
+
+## Configuration
+
+### `.datasecops.yml`
+
+Created by the setup script in your project root. Contains:
+
+```yaml
+connection_name: "my_connection"    # Snowflake connection name
+app_database: "DATA_ENGINEERS_DATASECOPS_FRAMEWORK"  # Native app database
+profile_name: ""                    # Auto-detected from dbt_project.yml
+```
+
+### `dbt_project.yml`
+
+The CLI reads the `profile:` field from your `dbt_project.yml` (looks in both `./dbt_project.yml` and `./dbt/dbt_project.yml`) to determine which project profile to load from the native app.
+
+### Snowflake Connection
+
+The CLI uses `snowflake-connector-python` with the connection name from `.datasecops.yml`. Connections are configured in `~/.snowflake/connections.toml`:
+
+```toml
+[my_connection]
+account = "my_account"
+user = "my_user"
+authenticator = "externalbrowser"
+warehouse = "MY_WH"
+role = "MY_ROLE"
+```
+
+## Project Structure
+
+```
+datasecops-cli/
+├── pyproject.toml                    # Package config, dependencies, entry point
+├── setup.sh                          # Bash setup (Linux/macOS)
+├── setup.ps1                         # PowerShell setup (Windows)
+├── .github/workflows/publish-cli.yml # PyPI publish workflow
+└── src/datasecops_cli/
+    ├── main.py                       # Entry point and main menu
+    ├── config.py                     # Configuration loader
+    ├── models/                       # Pydantic data models
+    ├── services/                     # Business logic (dbt, git, Snowflake, downloads)
+    ├── menus/                        # Interactive menu modules
+    └── utilities/                    # Display, file I/O, YAML helpers
+```
+
+## Publishing to PyPI
+
+The package is published automatically when a tag matching `cli-v*` is pushed:
+
+```bash
+git tag cli-v0.1.0
+git push origin cli-v0.1.0
+```
+
+The GitHub Actions workflow builds the package and publishes to PyPI using OIDC trusted publishing.
+
+To build and publish manually:
+
+```bash
+pip install build twine
+python -m build
+twine upload dist/*
+```
+
+## Native App API
+
+The CLI communicates with the native app through stored procedures:
+
+| Procedure | Purpose |
+|---|---|
+| `api.get_framework_config(code)` | Fetch any config by code (PROJECT, PIPELINES, SQLFLUFF_RULES, CORTEX_SKILLS, etc.) |
+| `api.get_project_profiles()` | List all project profiles |
+| `api.import_cortex_skills(json)` | Import skills into the native app |
+| `api.fetch_dbt_package_versions(json)` | Fetch latest package versions from GitHub |
+
+These procedures are granted to the `data_engineers_framework_admin` application role.

datasecops_cli-0.1.0/docs/legacy.md

@@ -0,0 +1,23 @@
+under the folder /legacy_framework/app/commandline is the legacy framework which this native app has replaced the configuration for.
+
+I want to re-create the command line segment so that users can still use it against the native app.
+It needs to:
+1 - ensure cortex code, uv and dbt (dbt fusion) is installed. If it isnt then needs to install them
+2 - select which connection they want to use
+3 - select the database name for the native app
+4 - create a venv under uv for the project to run under
+5 - ensure the packages are installed as defined in settings => requirements of the framework
+6 - the project profile to use should come from the dbtproject.yml file and needs to ensure a project profile exists inside the framework database
+7 - display option menus so a user can run dbt or git based commands.
+
+For the dbt run commands, the user needs to be able to run them under dbt fusion
+For the git commands, they need to be able to pull, push, checkout etc as per current menus, but they also need to be able to do a squash merge into test and cherry pick commits out of test.
+
+We also need the ability to download the config file for SQLFluff as well as the pipeline files and also bring down updated dbt package versions/revisions for the dbt dependancies.
+
+step 1, 2, 3, 4 need to be in a setup script (bash & ps based). Then download the framework command line package from pypi
+
+Create a plan of what we need to
+- build into the framework command line package
+- deployment path into pypi
+- scripts needed to be included in the local repo