Migrate release process from Makefile to GoReleaser

[Copilot]

Replaces manual Makefile-based binary building and artifact packaging with GoReleaser for the release workflow.

Changes

• .goreleaser.yml: GoReleaser v2 configuration

  • Builds 8 binaries (jaeger, remote-storage, tracegen, anonymizer, esmapping-generator, es-index-cleaner, es-rollover, hotrod) across 7 platforms
  • Packages into jaeger-*.tar.gz (jaeger + hotrod) and jaeger-tools-*.tar.gz (ES utilities)
  • Generates checksums and GPG signatures

• .github/workflows/ci-release.yml: Replace build/package steps

  • Use goreleaser/goreleaser-action instead of make build-all-platforms and package-deploy.sh
  • Snapshot mode for dry runs (no signing, no push)
  • Docker builds unchanged (use existing scripts with -B flag removed since they rebuild binaries)

• RELEASE.md: Document new process and local testing commands

Local Testing

# Validate configuration
go run github.com/goreleaser/goreleaser/v2@latest check

# Test build without publishing
go run github.com/goreleaser/goreleaser/v2@latest release --snapshot --clean --skip=sign

Artifacts remain identical: same naming, same checksums format, same GPG signatures.

Original prompt

the release process in this repo is done with make files. The main steps are in ci-release.yaml workflow. I want to replace this manual building and artifact pushing with goreleaser.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[yurishkuro]

@copilot You left docker image building / publishing still using the old script. Is goreleaser not able too push images too?

[Copilot]

@copilot You left docker image building / publishing still using the old script. Is goreleaser not able too push images too?

Yes, goreleaser can build and push Docker images. However, integrating it fully requires:

1. Dockerfile modifications: All Dockerfiles expect binaries named {binary}-linux-{arch} (e.g., jaeger-linux-amd64), but goreleaser uses its own naming convention. Each Dockerfile would need updates.

2. Base image handling: The current scripts create baseimg_alpine and debugimg_alpine base images that are referenced by Dockerfiles with build args.

3. Integration tests: The existing Docker build process runs integration tests (e.g., all-in-one-integration-test in build-all-in-one-image.sh) before pushing images.

4. Debug image variants: Some images (jaeger, remote-storage) have both release and debug variants with different entrypoints.

I recommend keeping Docker builds separate for this PR to maintain the current working process, then tackling Docker migration in a focused follow-up PR. This allows us to:

• Get the binary building improvements merged and tested first
• Design the Docker integration properly without rushing
• Avoid breaking the existing Docker CI/testing infrastructure

Would you prefer to keep it separate, or should I proceed with adding goreleaser Docker support in this PR?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.60%. Comparing base (d843097) to head (d401303).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7722      +/-   ##
==========================================
- Coverage   95.61%   95.60%   -0.02%     
==========================================
  Files         311      311              
  Lines       15511    15511              
==========================================
- Hits        14831    14829       -2     
- Misses        532      534       +2     
  Partials      148      148              

Flag	Coverage Δ
badger_v1	9.90% <ø> (ø)
badger_v2	2.07% <ø> (ø)
cassandra-4.x-v1-manual	14.05% <ø> (ø)
cassandra-4.x-v2-auto	2.06% <ø> (ø)
cassandra-4.x-v2-manual	2.06% <ø> (ø)
cassandra-5.x-v1-manual	14.05% <ø> (ø)
cassandra-5.x-v2-auto	2.06% <ø> (ø)
cassandra-5.x-v2-manual	2.06% <ø> (ø)
clickhouse	1.98% <ø> (ø)
elasticsearch-6.x-v1	18.80% <ø> (ø)
elasticsearch-7.x-v1	18.83% <ø> (ø)
elasticsearch-8.x-v1	19.00% <ø> (ø)
elasticsearch-8.x-v2	2.07% <ø> (ø)
elasticsearch-9.x-v2	2.07% <ø> (ø)
grpc_v1	9.69% <ø> (ø)
grpc_v2	2.07% <ø> (ø)
kafka-3.x-v2	2.07% <ø> (ø)
memory_v2	2.07% <ø> (ø)
opensearch-1.x-v1	18.88% <ø> (ø)
opensearch-2.x-v1	18.88% <ø> (ø)
opensearch-2.x-v2	2.07% <ø> (ø)
opensearch-3.x-v2	2.07% <ø> (ø)
query	2.07% <ø> (ø)
tailsampling-processor	0.59% <ø> (ø)
unittests	94.17% <ø> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.