You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 10, 2025. It is now read-only.
refactor: [#14] reorganize Makefile into infrastructure/application layers
- Restructure Makefile into clear hierarchical layers (infra-, app-, vm-, test-, dev-)
- Rename commands for better clarity: test -> test-e2e, test-syntax -> lint
- Remove backward compatibility for legacy commands (apply, destroy, ssh, etc.)
- Update help output with grouped commands by layer for better discoverability
- Update all scripts, tests, and documentation to use new command structure
- Implement twelve-factor app deployment workflow separation
- Infrastructure provisioning: make infra-apply (platform setup)
- Application deployment: make app-deploy (Build + Release + Run stages)
- VM access and debugging: make vm-ssh, vm-console, vm-status
- Testing: make test-e2e (comprehensive), make lint (syntax), make test-unit
- Development workflows: make dev-deploy, make dev-test, make dev-clean
Updated files:
- Makefile: Complete restructure with new command organization
- CI workflow: Updated to use make infra-test-ci
- Documentation: Updated all references to use new command names
- Test scripts: Updated to use new infra/app health check commands
- E2E test: Updated to use make lint instead of make test-syntax
This refactoring improves command discoverability, follows twelve-factor app
principles, and provides clear separation between infrastructure and application
concerns while maintaining all existing functionality.
4.**Test twelve-factor workflow**: Ensure both infrastructure provisioning and application deployment work
454
453
```bash
@@ -482,15 +481,15 @@ Be mindful of the execution context for different types of commands. The project
482
481
483
482
When executing commands on the remote VM, be aware of limitations with interactive sessions.
484
483
485
-
-**Problem**: The VS Code integrated terminal may not correctly handle commands that initiate a new interactive shell, such as `ssh torrust@<VM_IP>` or `make ssh`. The connection may succeed, but subsequent commands sent to that shell may not execute as expected, and their output may not be captured.
484
+
-**Problem**: The VS Code integrated terminal may not correctly handle commands that initiate a new interactive shell, such as `ssh torrust@<VM_IP>` or `make vm-ssh`. The connection may succeed, but subsequent commands sent to that shell may not execute as expected, and their output may not be captured.
486
485
487
486
-**Solution**: Prefer executing commands non-interactively whenever possible. Instead of opening a persistent SSH session, pass the command directly to `ssh`.
488
487
489
488
-**Don't do this**:
490
489
491
490
```bash
492
491
# 1. Log in
493
-
make ssh
492
+
make vm-ssh
494
493
# 2. Run command (this might fail or output won't be seen)
495
494
df -H
496
495
```
@@ -569,7 +568,7 @@ This ensures that the command is executed and its output is returned to the prim
569
568
**Pre-commit Testing Requirement**: ALWAYS run the CI test suite before committing any changes:
570
569
571
570
```bash
572
-
make test-ci
571
+
make infra-test-ci
573
572
```
574
573
575
574
This command runs all unit tests that don't require a virtual machine, including:
@@ -581,7 +580,7 @@ This command runs all unit tests that don't require a virtual machine, including
581
580
582
581
Only commit if all CI tests pass. If any tests fail, fix the issues before committing.
583
582
584
-
**Note**: End-to-end tests (`make test`) are excluded from pre-commit requirements due to their longer execution time (~5-8 minutes), but running them before pushing is strongly recommended for comprehensive validation.
583
+
**Note**: End-to-end tests (`make test-e2e`) are excluded from pre-commit requirements due to their longer execution time (~5-8 minutes), but running them before pushing is strongly recommended for comprehensive validation.
585
584
586
585
**Best Practice**: Always ask "Would you like me to commit these changes?" before performing any git state-changing operations.
0 commit comments