ethereum-optimism / ethereum-optimism/optimism
Use better tooling for generating op-node/batcher/proposer/challenger release notes
- Dominant language
- Go
- Stars
- 6.5k
- Forks
- 4k
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 145
Description
GoReleaser is already used for the `op-deployer` release pipeline.
We don't have a fully automated release pipeline for the main OP Stack components op-node/batcher/proposer/challenger yet. Docker builds happen via CI jobs but drafting the release notes, to only include commits that changed a file in the component's sub directory in question, is still a manual and error prone task. GoReleaser can greatly simplify this step because it can automatically filter to relevant commits.
However, GoReleaser can also fully take over the whole release process, including building binaries and Docker images. We could skip this in a first iteration though, to keep using the current CircleCI Docker build jobs.
I had some limited local success using GoReleaser for op-node with this config:
```yaml
# yaml-language-server: $schema=https://goreleaser.com/static/schema-pro.json
# vim: set ts=2 sw=2 tw=0 fo=cnqoj
version: 2
project_name: op-node
before:
hooks:
# You may remove this if you don't use go modules.
- go mod tidy
builds:
- id: main
main: ./cmd
binary: {{ .ProjectName }}
env:
- CGO_ENABLED=0
goos:
- linux
- windows
- darwin
goarch:
- amd64
- arm64
ignore:
- goos: windows
goarch: arm64
- goos: linux
goarch: arm64
mod_timestamp: "{{ .CommitTimestamp }}"
ldflags:
- -X main.GitCommit={{ .FullCommit }}
- -X main.GitDate={{ .CommitDate }}
- -X github.com/ethereum-optimism/optimism/{{ .ProjectName }}/version.Version={{ .Version }}
- -X github.com/ethereum-optimism/optimism/{{ .ProjectName }}/version.Meta=
archives:
- formats: tar.gz
# this name template makes the OS and Arch compatible with the results of `uname`.
name_template: "{{ .ProjectName }}-{{.Version}}-{{ tolower .Os }}-{{ .Arch }}"
# use zip for windows archives
wrap_in_directory: true
format_overrides:
- goos: windows
formats: zip
dockers:
- id: default
goos: linux
goarch: amd64
dockerfile: Dockerfile.default
image_templates:
- "us-docker.pkg.dev/oplabs-tools-artifacts/images/{{ .ProjectName }}:{{ .Tag }}"
changelog:
paths:
- {{ .ProjectName }}/
- go.mod
filters:
exclude:
- "^docs:"
- "^test:"
git:
tag_sort: semver
release:
github:
owner: ethereum-optimism
name: optimism
draft: true
make_latest: false
monorepo:
tag_prefix: {{ .ProjectName }}/
dir: {{ .ProjectName }}
```
I used it to draft the list of relevant commits for the [op-node/v1.13.3](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.13.3) release (I had ascending-by-message ordering enabled, which I removed from above config because I think historical ordering is actually better). Since the tag to release didn't contain the file, I had to move it outside the repo so GoReleaser doesn't complain about a dirty git repo. My invocation was `goreleaser release --clean -f ../.goreleaser.yaml`.
This config may already work in its templated form for all OP Stack components mentioned above. GoReleaser also supports inclusion of templates, so this could be mostly moved into a template that is then just imported in each component's `.goreleaser.yaml` file.
However, there are some open issues to sort out.
* We either skip the Docker build, and reuse our existing Docker build jobs, or need to create a Dockerfile that works for the components, possibly also in a templated form.
* I'm not sure if GoReleaser properly selects the correct commit range from current _finalized_ to the previous _finalized_ tag. It includes `-rc.N` tags in its ordering. We could filter out `rc` tags when using GoReleaser so it's only used for finalized tags. But this needs to be investigated.
Contributor guide
Research direction
Start by comparing the existing op-deployer GoReleaser setup with the proposed `.goreleaser.yaml` configuration and current CircleCI Docker jobs. Investigate GoReleaser's finalized-versus-rc tag range selection and component path filtering for op-node, batcher, proposer, and challenger. Done means the release-note drafts reliably contain only relevant finalized changes, with the existing Docker builds still usable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, github, go
- Domain
- build-system, ci-cd, release
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100