CI/CD Workflow

Overview

The Jaeger project’s CI/CD workflow is established using a combination of Makefile targets and GitHub Actions for continuous integration.

Makefile Configuration

The main interface for triggering CI-related actions is through the Makefile. Below are the important targets you can utilize, along with their respective descriptions:

1. install-dep: This target installs the dependency management tool dep if not already present.

   .PHONY: install-dep
   install-dep:
       - curl -L -s https://github.com/golang/dep/releases/download/v0.5.4/dep-linux-amd64 -o $$GOPATH/bin/dep
       - chmod +x $$GOPATH/bin/dep
   

2. install: This target installs dependencies using either dep or glide. Ensure you set USE_DEP or USE_GLIDE appropriately.

   .PHONY: install
   install:
   ifeq ($(USE_DEP),true)
       dep version || make install-dep
       dep version
       dep ensure -vendor-only
       dep status
   else ifeq ($(USE_GLIDE),true)
       glide --version || go get github.com/Masterminds/glide
       glide --version
       glide install
   endif
   

3. test-ci: This target runs checks for dependencies, coverage, and linting.

   .PHONY: test-ci
   test-ci: dep-check cover lint
   

4. test: Your default command when running make executes tests and linting.

   .DEFAULT_GOAL: test-and-lint
   .PHONY: test-and-lint
   test-and-lint: test
   

5. lint: This target performs static analysis using golint.

   .PHONY: lint
   lint:
       $(GOVET) ./...
       @cat /dev/null > $(LINT_LOG)
       @$(foreach pkg, $(PACKAGES), $(GOLINT) $(pkg) >> $(LINT_LOG) || true;)
       @[ ! -s "$(LINT_LOG)" ] || (echo "Lint Failures" | cat - $(LINT_LOG) && false)
       @$(GOFMT) -e -s -l $(ALL_SRC) > $(FMT_LOG)
   

6. cover: This target generates a coverage report.

   .PHONY: cover
   cover:
       $(GOTEST) -cover -coverprofile cover.out ./...
   

7. cover-html: This will create an HTML report of the coverage.

   .PHONY: cover-html
   cover-html: cover
       go tool cover -html=cover.out -o cover.html
   

Continuous Integration Setup

The CI setup is based on GitHub Actions, and you can find the workflow definitions within the GitHub repository. The following is a typical approach to ensure the workflow triggers appropriately:

• Pull requests are automatically run through the CI pipeline to validate changes.
• The workflow files are responsible for defining the steps for testing and static analysis.

For example, a workflow defined in .github/workflows/ci.yml might look like this:

name: CI

on: 
  push:
    branches: 
      - main
  pull_request:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
        
      - name: Set up Go
        uses: actions/setup-go@v2
        with:
          go-version: '1.16'
          
      - name: Install dependencies
        run: make install
        
      - name: Run tests
        run: make test

Release Workflow

For managing releases, follow the steps outlined in RELEASE.md:

1. Create a pull request with a title such as “Preparing release 2.1.0”.

2. Update the CHANGELOG.md with recent changes, retrieved using:

   git log --pretty=format:'- %s -- %an'
   

3. Once the PR is merged, create a GitHub release (e.g., v2.1.0).

Next Steps

If CI/CD features are not entirely set up, consider implementing the following:

• Set up necessary GitHub Actions for automated testing.
• Ensure all Makefile targets are well-documented and functioning.
• Frequently update the CI pipeline as code evolves.

This configuration ensures that every change made to the repository is verified through automated testing and code quality checks, leading to a more robust and reliable project.