|
| 1 | +# .github/workflows/go.yml |
| 2 | + |
| 3 | +name: Go Build and Test # Name of the workflow displayed on GitHub |
| 4 | + |
| 5 | +# Controls when the workflow will run |
| 6 | +on: |
| 7 | + push: |
| 8 | + branches: [ main ] # Run on pushes to the main branch |
| 9 | + pull_request: |
| 10 | + branches: [ main ] # Run on pull requests targeting the main branch |
| 11 | + |
| 12 | +# Defines the jobs that make up the workflow |
| 13 | +jobs: |
| 14 | + # The "build" job definition |
| 15 | + build: |
| 16 | + # Specify the runner environment (OS) |
| 17 | + # ubuntu-latest is a common and cost-effective choice |
| 18 | + runs-on: ubuntu-latest |
| 19 | + |
| 20 | + # Define the steps within the "build" job |
| 21 | + steps: |
| 22 | + # Step 1: Check out the repository's code |
| 23 | + # This action checks-out your repository under $GITHUB_WORKSPACE, so your workflow can access it. |
| 24 | + - name: Check out code |
| 25 | + uses: actions/checkout@v4 # Use v4 of the checkout action |
| 26 | + |
| 27 | + # Step 2: Set up the Go environment |
| 28 | + # This action sets up a Go environment for use in actions |
| 29 | + - name: Set up Go |
| 30 | + uses: actions/setup-go@v5 # Use v5 of the setup-go action |
| 31 | + with: |
| 32 | + # Specify the Go version. You can use: |
| 33 | + # - A specific version like '1.21' |
| 34 | + # - 'stable' for the latest stable Go version |
| 35 | + # - Use go-version-file to read from go.mod (recommended) |
| 36 | + go-version-file: 'go.mod' |
| 37 | + # Enable caching for Go modules and build cache for faster builds |
| 38 | + cache: true |
| 39 | + |
| 40 | + # Optional Step 3: Run Linters (Highly Recommended) |
| 41 | + # Uses golangci-lint, a popular Go meta-linter. |
| 42 | + # It aggregates many linters and runs them efficiently. |
| 43 | + - name: Run linters |
| 44 | + uses: golangci/golangci-lint-action@v6 # Use v6 of the action |
| 45 | + with: |
| 46 | + # Optional: version of golangci-lint to use, e.g. 'v1.55.2' or 'latest'. |
| 47 | + # Using 'latest' is convenient but might introduce unexpected changes. |
| 48 | + # Pinning to a specific version ensures reproducibility. |
| 49 | + version: latest |
| 50 | + # Optional: command line arguments. Add custom flags if needed. |
| 51 | + # args: --timeout=3m |
| 52 | + |
| 53 | + # Optional Step 4: Check Go code formatting |
| 54 | + # Ensures code adheres to standard 'gofmt' style. |
| 55 | + - name: Check formatting |
| 56 | + run: | |
| 57 | + # List files that differ from gofmt's output |
| 58 | + FMT_FILES=$(gofmt -l .) |
| 59 | + if [ -n "$FMT_FILES" ]; then |
| 60 | + echo "Go files need formatting:" |
| 61 | + echo "$FMT_FILES" |
| 62 | + exit 1 |
| 63 | + fi |
| 64 | + echo "Go code is correctly formatted." |
| 65 | +
|
| 66 | + # Step 5: Build the application |
| 67 | + # The '-v' flag provides verbose output. './...' builds all packages. |
| 68 | + - name: Build |
| 69 | + run: go build -v ./... |
| 70 | + |
| 71 | + # Step 6: Run tests |
| 72 | + # The '-v' flag provides verbose output. './...' tests all packages. |
| 73 | + # The '-race' flag enables the race detector (good for finding concurrency issues). |
| 74 | + - name: Test with race detector |
| 75 | + run: go test -v -race ./... |
0 commit comments