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
@@ -6,143 +6,34 @@ For each problem, I focus on the thought process rather than providing a full, f
6
6
7
7
Solutions may not be optimal, but they serve as a starting point for further improvement and learning.
8
8
9
-
# CI/CD setup
9
+
# CI/CD Setup
10
10
11
-
This repository uses GitHub Actions for automated testing with a **modular workflow architecture**. Instead of putting everything in one large workflow file, we separate concerns into multiple focused workflows:
11
+
This repository uses GitHub Actions with a **modular workflow architecture** for automated testing, code quality checks, security scanning, and builds.
I only used gitlab before so this note will mention some reference to gitlab but still trying to offer the concept of how CI/CD is setup in github acitons.
80
-
81
-
Please also check [text](https://docs.github.com/en/actions/tutorials/build-and-test-code/go) where it has a good starting example for go.
82
-
83
-
## Key Concepts
84
-
85
-
**GitHub Actions Basics:**
86
-
-**`uses`**: Runs pre-built actions instead of custom shell commands, good to check in [text](https://github.com/marketplace?query=checkout&type=actions)
87
-
-**`runs-on`**: Specifies what machine/VM to run the job on (like GitHub's free EC2)
88
-
-**`actions/checkout@v4`**: Downloads repository source code to the runner like running clone - cd - checkout
89
-
-**`.github/workflows/*.yml`**: GitHub's config location (vs GitLab's single `.gitlab-ci.yml`)
90
-
91
-
**Matrix Strategy (Parallel Jobs):**
92
-
-**`strategy` + `matrix`**: Creates parallel jobs with different configurations (like GitLab's parallel:matrix)
93
-
-**Cross-platform testing**: Simply use multiple OS runners (ubuntu/windows/macos)
94
-
95
-
**Caching (Speed Optimization):**
96
-
-**`actions/cache@v4`**: Speeds up workflows by saving/restoring files between CI/CD runs
97
-
-**`path`**: What directory/files to cache (~/go/pkg/mod for Go modules)
98
-
-**`key`**: Unique identifier for the cache (includes OS, Go version, dependency hash)
99
-
-**`restore-keys`**: Fallback cache keys to try if exact match not found
100
-
-**Cache timing**: Restore happens on the step of actions/cache, save happens automatically at job end. go actions has its own caching mechanism, this repo use the custom cache just to show one of the machanism for caching.
101
-
-**Cache fallback**: Uses partial matches when dependencies change incrementally, but still try to get the previous installed packages
102
-
103
-
**Go Commands:**
104
-
-**`go test -v`**: Runs tests with verbose output showing individual test names
105
-
-**`go build`**: Compiles Go source code into executables (compilation verification)
106
-
-**`find . -name "go.mod" -execdir`**: Finds all Go modules and runs commands in their directories
107
-
108
-
## Best Practice: Workflow Separation
109
-
110
-
### ❌ **Anti-pattern: Monolithic Workflow**
111
-
```yaml
112
-
# DON'T: Everything in one job
113
-
jobs:
114
-
everything:
115
-
steps:
116
-
- name: Test
117
-
- name: Lint
118
-
- name: Security scan
119
-
- name: Build
120
-
- name: Deploy
121
-
```
122
-
123
-
### ✅ **Best Practice: Modular Workflows**
124
-
```yaml
125
-
# DO: Separate files for different concerns
126
-
.github/workflows/
127
-
├── test.yml # Testing only
128
-
├── code-quality.yml # Linting & formatting
129
-
├── security.yml # Vulnerability scanning
130
-
├── build.yml # Cross-compilation
131
-
└── deploy.yml # Deployment (if needed)
132
-
```
133
-
134
-
### **Why Separation Matters:**
135
-
136
-
1.**🚀 Faster Feedback**: Get quality issues immediately without waiting for all tests
137
-
2.**🔄 Independent Scaling**: Add more test scenarios without affecting code quality checks
138
-
3.**🎯 Focused Debugging**: When a workflow fails, you know exactly which aspect broke
139
-
4.**👥 Team Ownership**: Different team members can maintain different workflows
140
-
5.**📊 Better Metrics**: Track success rates for testing vs. code quality vs. security separately
141
-
6.**🔧 Selective Execution**: Disable specific checks (e.g., security scanning) without affecting core testing
142
-
143
-
This modular approach follows the **Single Responsibility Principle** in CI/CD design, making your development process more maintainable and scalable.
144
-
145
-
## Local testing
36
+
## Local Testing
146
37
147
38
To run tests locally for a specific problem:
148
39
@@ -155,4 +46,6 @@ To run tests with race detection:
155
46
156
47
```bash
157
48
go test -race -v ./...
158
-
```
49
+
```
50
+
51
+
For complete CI/CD setup instructions and concepts, see the [CI/CD documentation](docs/).
This document explains key CI/CD concepts, particularly focusing on GitHub Actions compared to other systems like GitLab CI.
4
+
5
+
*Note: I only used GitLab before so this note will mention some reference to GitLab but still trying to offer the concept of how CI/CD is setup in GitHub Actions.*
6
+
7
+
Please also check [GitHub's Go tutorial](https://docs.github.com/en/actions/tutorials/build-and-test-code/go) where it has a good starting example for Go.
8
+
9
+
## GitHub Actions Basics
10
+
11
+
### Core Concepts
12
+
13
+
**Workflows vs Jobs vs Steps:**
14
+
-**Workflow**: A complete CI/CD process defined in `.github/workflows/*.yml`
15
+
-**Job**: A set of steps that run on the same runner machine
16
+
-**Step**: Individual commands or actions within a job
17
+
18
+
**Key Components:**
19
+
-**`uses`**: Runs pre-built actions instead of custom shell commands, good to check in [GitHub Marketplace](https://github.com/marketplace?query=checkout&type=actions)
20
+
-**`runs-on`**: Specifies what machine/VM to run the job on (like GitHub's free EC2)
21
+
-**`actions/checkout@v4`**: Downloads repository source code to the runner like running `git clone && cd repo && git checkout`
22
+
-**`.github/workflows/*.yml`**: GitHub's config location (vs GitLab's single `.gitlab-ci.yml`)
23
+
24
+
### Comparison with GitLab CI (check only if you know gitlab)
25
+
26
+
| GitHub Actions | GitLab CI | Purpose |
27
+
|----------------|-----------|---------|
28
+
|`uses: actions/checkout@v4`|`git clone` (automatic) | Get source code |
1. **Separate Concerns**: Different workflows for different purposes
95
+
2. **Clear Naming**: Use descriptive job and step names
96
+
97
+
### Performance Optimization
98
+
99
+
1. **Use Caching**: Cache dependencies and build artifacts
100
+
2. **Minimal Runners**: Use appropriate runner sizes (don't over-provision), they have all kinds of cost (money, and save some carbon output if you care!)
101
+
102
+
### ⚠️ Security Considerations
103
+
104
+
1. **Secrets Management**: Use GitHub Secrets for sensitive data
105
+
2. **Dependency Scanning**: Regular vulnerability checks upon the packages you use, the vulnerability reports are maintained by trustworthy officials. For Go, this uses:
106
+
- **Go Vulnerability Database**: https://vuln.go.dev/ - Official database maintained by Go security team
107
+
- **Documentation fpr `govulncheck`**: https://go.dev/security/vuln/ - Go's official vulnerability management
108
+
3. **Supply Chain Security**: Pin action versions (`@v4` not `@main`) and all dependencies, use specific version if you know that is more stable and meets the requirement rather than `@main` or `latest`!
0 commit comments