|
| 1 | +# Introduction |
| 2 | + |
| 3 | +This repository contains notes and solutions for selected coding exercises, with examples of automated testing and CI/CD workflows. |
| 4 | + |
| 5 | +For each problem, I focus on the thought process rather than providing a full, final solution. That includes analysis of time and space complexity, discussion of constraints, intuition, and invariants used to reason about correctness. |
| 6 | + |
| 7 | +Solutions may not be optimal, but they serve as a starting point for further improvement and learning. |
| 8 | + |
| 9 | +# CI/CD setup |
| 10 | + |
| 11 | +This repository uses GitHub Actions for automated testing. The workflow: |
| 12 | + |
| 13 | +- **Triggers**: Runs on pushes to `main`/`develop` branches and pull requests to `main` |
| 14 | +- **Go versions**: Tests against Go 1.21, 1.22, and 1.23 for compatibility |
| 15 | +- **Test steps**: |
| 16 | + 1. Downloads dependencies for all Go modules in the repository |
| 17 | + 2. Runs tests with `go test -v ./...` |
| 18 | + 3. Runs tests with race detector enabled |
| 19 | + 4. Verifies code builds successfully |
| 20 | + |
| 21 | + |
| 22 | +Each problem directory with a `go.mod` file is automatically discovered and tested independently. |
| 23 | + |
| 24 | + |
| 25 | + |
| 26 | +# Notes on CI/CD |
| 27 | + |
| 28 | +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. |
| 29 | + |
| 30 | +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. |
| 31 | + |
| 32 | +## Key Concepts |
| 33 | + |
| 34 | +**GitHub Actions Basics:** |
| 35 | +- **`uses`**: Runs pre-built actions instead of custom shell commands, good to check in [text](https://github.com/marketplace?query=checkout&type=actions) |
| 36 | +- **`runs-on`**: Specifies what machine/VM to run the job on (like GitHub's free EC2) |
| 37 | +- **`actions/checkout@v4`**: Downloads repository source code to the runner like running clone - cd - checkout |
| 38 | +- **`.github/workflows/*.yml`**: GitHub's config location (vs GitLab's single `.gitlab-ci.yml`) |
| 39 | + |
| 40 | +**Matrix Strategy (Parallel Jobs):** |
| 41 | +- **`strategy` + `matrix`**: Creates parallel jobs with different configurations (like GitLab's parallel:matrix) |
| 42 | +- **Cross-platform testing**: Simply use multiple OS runners (ubuntu/windows/macos) |
| 43 | + |
| 44 | +**Caching (Speed Optimization):** |
| 45 | +- **`actions/cache@v4`**: Speeds up workflows by saving/restoring files between CI/CD runs |
| 46 | +- **`path`**: What directory/files to cache (~/go/pkg/mod for Go modules) |
| 47 | +- **`key`**: Unique identifier for the cache (includes OS, Go version, dependency hash) |
| 48 | +- **`restore-keys`**: Fallback cache keys to try if exact match not found |
| 49 | +- **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. |
| 50 | +- **Cache fallback**: Uses partial matches when dependencies change incrementally, but still try to get the previous installed packages |
| 51 | + |
| 52 | +**Go Commands:** |
| 53 | +- **`go test -v`**: Runs tests with verbose output showing individual test names |
| 54 | +- **`go build`**: Compiles Go source code into executables (compilation verification) |
| 55 | +- **`find . -name "go.mod" -execdir`**: Finds all Go modules and runs commands in their directories |
| 56 | + |
| 57 | +## Local testing |
| 58 | + |
| 59 | +To run tests locally for a specific problem: |
| 60 | + |
| 61 | +```bash |
| 62 | +cd "Problem Directory" |
| 63 | +go test -v ./... |
| 64 | +``` |
| 65 | + |
| 66 | +To run tests with race detection: |
| 67 | + |
| 68 | +```bash |
| 69 | +go test -race -v ./... |
| 70 | +``` |
0 commit comments