-
Notifications
You must be signed in to change notification settings - Fork 1
Add Docker & Ansible configs #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add enhanced example configurations demonstrating Docker containerization and Ansible deployment capabilities: - rust-axum-example-docker.yaml: Dockerized Rust Axum examples with port bindings and cargo caching - rust-axum-example-ansible.yaml: Ansible deployment for Rust Axum examples with remote host support - golang-example-docker.yaml: Dockerized Go examples with module caching and port bindings - golang-example-ansible.yaml: Ansible deployment for Go examples with remote host support Updated examples/README.md with comprehensive documentation covering: - Setup instructions for basic, Docker, and Ansible configurations - Feature highlights for each deployment method - Configuration options explanation - Usage tips and best practices These examples complement the existing basic configurations and provide practical references for users implementing containerized builds and remote deployments.
Replace separate Docker and Ansible configuration files with unified enhanced configurations that support both execution modes. Changes: - Remove: golang-example-docker.yaml, golang-example-ansible.yaml - Remove: rust-axum-example-docker.yaml, rust-axum-example-ansible.yaml - Add: golang-example-enhanced.yaml with both containered_opts and ansible_opts - Add: rust-axum-example-enhanced.yaml with both containered_opts and ansible_opts Benefits: - Single configuration file per project instead of multiple variants - Choose execution mode at runtime with -d (Docker) or -a (Ansible) flags - Easier maintenance - update one file instead of three - Clearer demonstration of Deployer's flexibility Updated examples/README.md to reflect the new consolidated approach with clear instructions for each execution mode.
Replace separate basic and enhanced configuration files with unified configs that include both basic and enhanced pipelines in one file. Changes: - golang-example.yaml: Now includes both basic and enhanced pipelines - rust-axum-example.yaml: Now includes both basic and enhanced pipelines - Remove: golang-example-enhanced.yaml (merged into golang-example.yaml) - Remove: rust-axum-example-enhanced.yaml (merged into rust-axum-example.yaml) Benefits: - Simpler structure: One config file per project instead of two - Better UX: Users get all options (basic, Docker, Ansible) in one place - Easier to maintain: Single source of truth per example - Clear separation: Basic pipelines for simple use, enhanced pipelines for Docker/Ansible support Updated examples/README.md to reflect the unified structure with clear documentation on choosing between basic and enhanced pipelines.
Move Docker and Ansible options directly into existing pipelines instead of creating separate -enhanced variants. Users now choose execution mode at runtime with CLI flags. Changes: - golang-example.yaml: Add containered_opts and ansible_opts to hello, helloserver, and outyet pipelines - rust-axum-example.yaml: Add containered_opts and ansible_opts to hello, readme, and todos pipelines - Remove all -enhanced pipeline variants Benefits: - Simpler UX: Same pipeline name, different execution modes - No suffix confusion: Just use -d for Docker, -a for Ansible - Cleaner config: 3 pipelines instead of 6 per example - More intuitive: depl run hello / depl run hello -d / depl run hello -a Updated examples/README.md to reflect this streamlined approach.
Split cache strategies into two stages to maximize Docker layer caching efficiency. Dependencies are now cached separately from source code, preventing cache invalidation when only example code changes. Changes: - golang-example.yaml: Separate go.mod/go.sum download from source copy - Stage 1: Copy go.mod + go.sum, run go mod download - Stage 2: Copy source code, run build - rust-axum-example.yaml: Separate Cargo manifest fetch from source copy - Stage 1: Copy Cargo.toml + Cargo.lock, run cargo fetch - Stage 2: Copy examples/ source, run build Benefits: - Dependency layer is cached and reused when only source code changes - Faster rebuilds: No need to re-download dependencies on code updates - Follows Docker best practices for multi-stage caching - Significant time savings for iterative development Example: Changing a single .go or .rs file now only rebuilds from the source copy stage, keeping the dependency download layer cached.
Fix cache strategy structure and remove unnecessary file copies: 1. Each pipeline now only copies its own directory: - hello pipeline: only copies hello/ - helloserver pipeline: only copies helloserver/ - outyet pipeline: only copies outyet/ 2. Maintained proper cache strategy structure: - Stage 1: Copy go.mod + go.sum, run go mod download - Stage 2: Copy specific example directory, run DEPL Benefits: - Smaller Docker images (only includes needed source) - Faster builds (less data to copy) - Better cache isolation between pipelines - Follows single-responsibility principle Note: Rust examples keep copying the full examples/ directory since all examples are in a shared Cargo workspace and cannot be separated.
|
Looks like there are a few issues preventing this PR from being merged!
If you'd like me to help, just leave a comment, like Feel free to include any additional details that might help me get this PR into a better state. You can manage your notification settings |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.