feat: automate ci/cd for otto #11
Conversation
Implements GitHub issues open-telemetry#4 and open-telemetry#5: - Added GoReleaser configuration for building and releasing - Created a scratch-based Docker container for improved security and smaller size - Enhanced Makefile with additional utilities for development (linting, formatting, etc.) - Added version tracking and display in health endpoint - Created GitHub Actions workflow for automated releases
|
FWIW the linter failures are fixed on #10 so when that goes in and we rebase this it'll be green |
- Replace tag-based release with PR-based release workflow using labels - Add docker_manifests for multi-architecture image support - Add proper platform-specific Docker build configurations - Create RELEASING.md to document the release process - Remove redundant release workflow file 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
- Add binary signing configuration to GoReleaser - Add Docker image signing configuration - Update GitHub workflow to install Cosign and use secrets - Add documentation for signature verification - Update future improvements section 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
- Add svu integration for semantic versioning - Add conventional commits validation workflow - Configure fallback version for new repositories 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Replace ytanikin/pr-conventional-commits with amannn/action-semantic-pull-request for improved conventional commits validation in PRs. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
austinlparker
changed the title
There was a problem hiding this comment.
Pull Request Overview
This PR automates CI/CD for Otto by introducing new configurations for building, releasing, and version tracking. Key changes include:
- Implementing GoReleaser configurations for producing binaries and Docker images with a scratch base image.
- Updating internal logging to include version information.
- Adding and updating GitHub Actions workflows and release documentation.
Reviewed Changes
Copilot reviewed 9 out of 11 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| otto/internal/version.go | Added version variable and getter for build-time version injection. |
| otto/internal/app.go | Updated startup log to include the Otto version for better observability. |
| otto/RELEASING.md | New documentation outlining the release process and Docker image details. |
| otto/.svu.yml | Introduced configuration for version tagging in releases. |
| otto/.goreleaser.yaml | Full GoReleaser configuration for building, signing, and releasing Otto. |
| .github/workflows/test.yml | Extended the test workflow with additional build check steps. |
| .github/workflows/otto-release.yaml | Created a release workflow that automates tag creation and deployment. |
| .github/workflows/otto-commitlint.yml | Added a commit lint workflow to enforce conventional commits on Otto PRs. |
Files not reviewed (2)
- otto/Dockerfile.goreleaser: Language not supported
- otto/Makefile: Language not supported
.github/workflows/otto-release.yaml
Outdated
| # PR-based release trigger only | ||
| on: | ||
| pull_request: | ||
| types: [closed] |
There was a problem hiding this comment.
I'm unsure if we should change this in this pull request, but this would run on a pr close (which could be a merge, but also could be a "i'm closing this pull request"). I think release should only run on push to main.
There was a problem hiding this comment.
Re: Releasing
semantic-release and go-semantic-release are pretty standard for doing releases in the industry. They're fairly opinionated, but quite good. they rely of course on the conventional commits standard.
These are usually my default recommendation when doing any type of trunk based development. Of course, you can make the workflow a dispatch.
Neither of those tools support monorepo versioning from the perspective of multiple versions within a single repo based on path. That may be ok. Since otto doesn't publish versions of it's internal modules to be consumed, then there's no need to try to add multiple versions unless you want a prefix.
I'm generally not a fan of pull request based releases (release-please-esq). I will absolutely concede though to the wider decision.
There was a problem hiding this comment.
If you want, I can try to find sometime to push a change here.
- Add release-please-config.json and .release-please-manifest.json for version tracking - Create release-management.yml workflow using release-please-action - Update goreleaser workflow to work with release-please tags - Update documentation with conventional commits guidelines - Normalize GitHub workflow file names and structure
|
@adrielp i went through and (think) i have release-please set up in monorepo mode. i think this will work as long as we don't have weird cross-dependencies or anything (which I think will be the case, i'm not sure if we're ever gonna publish libs out of this repo) but lmk if it looks solid to you |
| fetch-depth: 0 | ||
|
|
||
| # Check if we need to run the release for Otto | ||
| - name: Download workflow artifact |
There was a problem hiding this comment.
Downloading the workflow run artifacts and writing some custom javascript to do so seems unnecessary. There are some actions that already do this in the event it is necessary.
| id: release-info | ||
| if: steps.download-artifact.outputs.result == 'true' | ||
| run: | | ||
| if [ -f "otto--release_created" ]; then |
There was a problem hiding this comment.
I was struggling (until I read the next workflow) to figure out where ott-release_created was coming from. It seems like the Gist of this is to have the binares and images built against the newly created release.
Instead of shipping up a specific artifact to read and detect later, another approach would be having this workflow trigger on a release created event.
| uses: googleapis/release-please-action@v4 | ||
| id: release | ||
| with: | ||
| token: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
fwiw, the default GITHUB_TOKEN won't trigger trigger events that other pipelines consume. For the release artifact, I'd encourage using the bot (github app) token instead.
| @@ -0,0 +1,3 @@ | |||
| { | |||
| "otto": "0.1.0" | |||
There was a problem hiding this comment.
Just curious, does release-please auto update and commit this on every release?
adrielp
left a comment
adrielp
left a comment
There was a problem hiding this comment.
Overall good. Suggested a couple minor changes but going to go ahead and approve as to not block any longer.
2 participants
Summary
Fixes #4: Improve Otto Docker container with scratch base image
Fixes #5: Add additional Makefile helpers for otto
Test plan