main
claude/smbcloud-github-app-k9641p
development
feature/apps
feature/build-release
feature/ci-docs
feature/ci-ruby-gems
feature/cicd
feature/completion
feature/dist-nuget
feature/fix-ci-sdk-pypi-rubygem
feature/fix-clippy-on-stable-channel
feature/fix-deployment-script
feature/github-email
feature/gresiq-v1
feature/project-new-structure
feature/rsync-deploy
feature/ruby-runner
feature/sdk-npm
feature/sdk-workflows
feature/smbcloud-cli-release-npm
feature/smbcloud-deploy
feature/wasm
main
release/v0.7.4
| 1 | //! smbCloud build and deploy engine. |
| 2 | //! |
| 3 | //! This crate holds the deploy logic: runner detection, config resolution, |
| 4 | //! per-runtime build strategies, and transport. It has no front-end of its own. |
| 5 | //! The CLI, the CI action, and the server-side git receiver all drive the same |
| 6 | //! engine; they differ only in how they report progress and how they |
| 7 | //! authenticate. |
| 8 | //! |
| 9 | //! Two things are inverted so the engine stays reusable. [`Reporter`] takes the |
| 10 | //! place of direct `spinners`, `dialoguer`, and `println!` calls, so the engine |
| 11 | //! never owns the terminal. Auth is passed in (a token or credentials); the |
| 12 | //! engine never reads `~/.smb` or prompts for login. |
| 13 | //! |
| 14 | //! Interactive setup (creating or selecting a project, writing |
| 15 | //! `.smb/config.toml`) stays in the front-end. The engine takes a resolved |
| 16 | //! config, or returns [`DeployError::NeedsSetup`] for the caller to handle. |
| 17 | |
| 18 | pub mod build; |
| 19 | pub mod error; |
| 20 | pub mod known_hosts; |
| 21 | pub mod report; |
| 22 | pub mod runner; |
| 23 | pub mod transport; |
| 24 | |
| 25 | pub use build::{BuildArtifact, BuildStrategy, SvelteKitAdapter, SvelteKitBuild, ViteSpaBuild}; |
| 26 | pub use error::DeployError; |
| 27 | pub use report::{NoopReporter, Reporter}; |
| 28 | pub use runner::detect_runner; |
| 29 | pub use transport::{RsyncTransport, Transport}; |