Skip to content

feat: Added goreleaser config for generating release notes and pre release creation #2788

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+120 −0
Open

feat: Added goreleaser config for generating release notes and pre release creation #2788

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 47 additions & 0 deletions .github/workflows/pre-release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
name: Pre-release

on:
push:
tags:
- 'v*'

permissions:
contents: write
discussions: write

jobs:
build-and-create-prerelease:
runs-on: ubuntu-latest
steps:
- name: Checkout (full history)
uses: actions/checkout@v4
with:
fetch-depth: 0

- name: Set up Go
uses: actions/setup-go@v5
with:
go-version-file: 'go.mod'
id: go
- name: Extract versions from go.mod
id: versions
run: |
# Extract Go version from go.mod
GO_VERSION=$(grep '^ARG GOVERSION=' Dockerfile | cut -d'=' -f2)
echo "go-version=${GO_VERSION}" >> $GITHUB_OUTPUT

# Extract k8s.io/client-go version from go.mod
CLIENT_GO_VERSION=$(go list -m -f '{{.Version}}' k8s.io/client-go)
echo "client-go-version=${CLIENT_GO_VERSION}" >> $GITHUB_OUTPUT

echo "📦 Go version: ${GO_VERSION}"
echo "📦 k8s.io/client-go version: ${CLIENT_GO_VERSION}"
- name: Make pre-release
uses: goreleaser/goreleaser-action@v6
with:
version: latest
args: release --clean
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GO_VERSION: ${{ steps.versions.outputs.go-version }}
K8S_CLIENT_VERSION: ${{ steps.versions.outputs.client-go-version }}
73 changes: 73 additions & 0 deletions .goreleaser.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
version: 2

archives:
- formats: [tar.gz]
# this name template makes the OS and Arch compatible with the results of `uname`.
name_template: >-
{{ .ProjectName }}_
{{- title .Os }}_
{{- if eq .Arch "amd64" }}x86_64
{{- else if eq .Arch "386" }}i386
{{- else }}{{ .Arch }}{{ end }}
{{- if .Arm }}v{{ .Arm }}{{ end }}

changelog:
use: github
sort: asc
groups:
- title: "Features"
regexp: "(?i)(feat|feature|\\[feature\\]|\\[feat\\]|\\bFEATURE\\b)"
order: 1
- title: "Bug Fixes"
regexp: "(?i)(fix|bugfix|\\[bugfix\\]|\\[BUGFIX\\]|\\bBUGFIX\\b)"
order: 2
- title: "Documentation"
regexp: "(?i)(docs?|documentation|\\[docs?\\])"
order: 3
- title: "Dependencies"
regexp: "(?i)(build\\(deps\\)|bump|dependencies)"
order: 4
- title: "Maintenance"
regexp: "(?i)(chore|refactor|\\[chore\\])"
order: 5
- title: "Other Changes"
regexp: ".*"
order: 99

filters:
exclude:
- '^docs:'
- '^test:'
- 'merge conflict'
- 'Merge branch'
- 'Merge pull request'

release:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussions should allow user to report concerns between the prerelease-to-release period.

  # If set, will create a release discussion in the category specified.
  #
  # Warning: do not use categories in the 'Announcement' format.
  #  Check https://github.com/goreleaser/goreleaser/issues/2304 for more info.
  #
  # Default: ''.
  discussion_category_name: Releases

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering if we can close the discussions once that period is over?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope we need to do that manually

github:
owner: kubernetes
name: kube-state-metrics

prerelease: "true"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First a release candidate (e.g. v1.2.0-rc.0) should be cut. If after a period of 7 days no bugs or issues were reported after publishing the release candidate, a stable release (e.g. v1.2.0) can be cut.

Do we plan on running a prerelease: false workflow after 7 days?

Copy link
Contributor Author

@Rishab87 Rishab87 Oct 2, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of creating a seperate post release workflow (for merging back to main and running kpromo first) after which we can mark the release as the main release manually (we need to do mark it as main manually because it needs to be done after the merging of the kpromo PR & the 7 day wait period).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather see that automated after a 7-day cron, mostly because it's easy to lose track of. Also, I believe the kpromo and "merging back into main" effort needs to be done for the pre-release too, ideally, all release steps need to be done for both pre-release and final release, so they may be sourced from a single script.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool, I'll create a seperate PR with cron to check for pre release and mark it as main

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just checked the krpomo and merging back to main does not needs to be done for pre-release, it needs to be done before marking the release as main, this is what is mentioned in RELEASE.md, please do correct if I'm wrong, so do we still need a cron? Since we have to manually run post release after prow build is finished and then merge the PRs after 7 days.

Copy link
Member

@rexagod rexagod Oct 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I guess it made sense to do a kpromo promotion for pre-release as well, so users can test out the image. But since we don't do that at the moment, and no one's asked us to do that anyway, let's keep it as you mentioned.


header: |
## {{ .Tag }} / {{ .Now.Format "2006-01-02" }}

{{- if index .Env "GO_VERSION" }}
## Note
- This release builds with Go `{{ index .Env "GO_VERSION" }}`
{{- end }}

{{- if index .Env "K8S_CLIENT_VERSION" }}
- This release builds with `k8s.io/client-go`: `{{ index .Env "K8S_CLIENT_VERSION" }}`
{{- end }}

footer: |
**Full Changelog**: {{ .GitURL }}/compare/{{ .PreviousTag }}...{{ .Tag }}

mode: replace
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

  # You can add extra pre-existing files to the release.
  # The filename on the release will be the last part of the path (base).
  # If another file with the same name exists, the last one found will be used.
  #
  # Templates: allowed.
  extra_files:
    - glob: ./path/to/file.txt
    - glob: ./glob/**/to/**/file/**/*
    - glob: ./glob/foo/to/bar/file/foobar/override_from_previous
    - glob: ./single_file.txt
      name_template: file.txt # note that this only works if glob matches 1 file only

I believe we'll need to use this to export the openvex and SBOMs? Or is that done without this already?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

they're built currently on creating a main release automatically, I don't think we should add them in pre-release here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, not sure if we should skip them for pre-releases, I'd rather keep the pre-release and release workflow as coherent as possible, so the pre-release artifacts can be inspected as well. This pattern will allow us to have a nearly identical release copy to verify.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so for that I can create a seperate PR changing the existing workflow which exports openvex and sboms to run on both pre release and release?


# If set, will create a release discussion in the category specified.
# Warning: do not use categories in the 'Announcement' format.
# Check https://github.com/goreleaser/goreleaser/issues/2304 for more info.
# Default: ''.
discussion_category_name: Releases