Skip to content
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.

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

Automate releases #334

Merged
merged 1 commit into from
Mar 3, 2021
Merged

Automate releases #334

merged 1 commit into from
Mar 3, 2021

Conversation

k0da
Copy link
Collaborator

@k0da k0da commented Mar 1, 2021

* Adds separate Dockerfile for each architecture to keep base image
  unchanged.
* Brings github_changelog_generator into a release pipeline
* Add .goreleaser.yaml with go build and amd64/arm64 images with docker
  common manifest
* Introduce pipeline for tag event, where docker artifacts will be
  built.
* Rename helm pipeline (release) into helm_publish

Signed-off-by: Dinar Valeev dinar.valeev@absa.africa

@ytsarev
Copy link
Member

ytsarev commented Mar 1, 2021

@somaritane keen to release v0.7.6 using this one?

UPD: ok, too late :D

Copy link
Member

@ytsarev ytsarev left a comment

Choose a reason for hiding this comment

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

Looks super fancy, just some clarifications required

.goreleaser.yml Outdated
filters:
exclude:
- '^docs:'
- '^test:'
Copy link
Member

Choose a reason for hiding this comment

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

Why exclude them?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is upstream behaviour and ignored by providing --release-notes flag, https://goreleaser.com/customization/release/#custom-release-notes

Copy link
Member

Choose a reason for hiding this comment

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

I get it, just don't think we should exclude docs or tests from the changelog :)

docker_manifests:
- name_template: absaoss/k8gb:{{ .Tag }}
image_templates:
- absaoss/k8gb:{{ .Tag }}-amd64
Copy link
Member

Choose a reason for hiding this comment

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

Will the final tag include $arch suffix?

If yes, it will break this logic https://github.com/AbsaOSS/k8gb/blob/master/chart/k8gb/templates/operator.yaml#L29

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It follows same strategy as of now. We build two images imag-{.Arch} then wrap it with single manifest name_template: absaoss/k8gb:{{ .Tag }}

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

So it won't break Deployment manifest. absaoss/k8gb:{{ .Tag }} will resolve into absaoss/k8gb:{{ .Tag }}-amd64 if kubernetes worker is amd64

Copy link
Member

Choose a reason for hiding this comment

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

Cool!

checksum:
name_template: 'checksums.txt'
snapshot:
name_template: "{{ .Tag }}-next"
Copy link
Member

Choose a reason for hiding this comment

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

Can you elaborate on the logic here?

Copy link
Collaborator Author

@k0da k0da Mar 1, 2021

Choose a reason for hiding this comment

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

you can run goreleaser --snapshot, it will build image: image:tag-next

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@somaritane
Copy link
Contributor

@somaritane keen to release v0.7.6 using this one?

@ytsarev, Oops, I've just released v0.7.6 now, but v0.7.7 - definitely :)

@ytsarev
Copy link
Member

ytsarev commented Mar 1, 2021

@k0da will it create Draft Release or Release right away?

@k0da
Copy link
Collaborator Author

k0da commented Mar 1, 2021

If set to true, will not auto-publish the release.

Default is false.

draft: false

Release straighaway. I think we should start with draft first

@somaritane
Copy link
Contributor

somaritane commented Mar 1, 2021

I think we should start with draft first

Makes sense. github-changelog-generator uses GH issue's tags for changelog generation, which might require 2nd pair of eyes to check that issues are correctly categorized

@k0da
Copy link
Collaborator Author

k0da commented Mar 1, 2021

amended

Copy link
Member

@ytsarev ytsarev left a comment

Choose a reason for hiding this comment

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

@k0da what about we create some fake releases and see how it works end-to-end?

.goreleaser.yml Outdated
snapshot:
name_template: "{{ .Tag }}-next"
changelog:
sort: asc
Copy link
Member

Choose a reason for hiding this comment

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

is it about goreleaser based changelog? Will it be completely overriden by github_changelog_genererator? If yes we probably can omit this option

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, I'll drop it.

@k0da
Copy link
Collaborator Author

k0da commented Mar 2, 2021

@k0da what about we create some fake releases and see how it works end-to-end?

I can tag local commit with v0.7.7-alpha1 and run releaser manually?

@k0da k0da force-pushed the releaser branch 2 times, most recently from d65ae3a to 7d519e9 Compare March 2, 2021 09:19
ytsarev
ytsarev previously approved these changes Mar 2, 2021
Copy link
Member

@ytsarev ytsarev left a comment

Choose a reason for hiding this comment

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

https://github.com/AbsaOSS/k8gb/releases/tag/untagged-d1d7bd1b09241abe6eb0 looks great, so let's accommodate the cool pipes :)

somaritane
somaritane previously approved these changes Mar 2, 2021
Copy link
Contributor

@somaritane somaritane left a comment

Choose a reason for hiding this comment

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

lgtm

@k0da k0da dismissed stale reviews from somaritane and ytsarev via 76b2d61 March 2, 2021 12:17
@k0da k0da requested review from somaritane and ytsarev March 2, 2021 13:03
@@ -109,3 +109,6 @@ chart/k8gb/charts/*.tgz

# Ignore testing kubeconfigs
kubeconfig*

# Ignore changes from github_changelog_generator action
changes
Copy link
Member

Choose a reason for hiding this comment

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

How do we update CHANGELOG.md in this scenario?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

same way as before, post release commit (post release github_changelog_generator on maintainers machine and open PR).
During GH run only temporary diff is generated into gitingored file.

Copy link
Member

Choose a reason for hiding this comment

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

But before local github_changelog_generator diff was the input for release. Now it will be required to run it locally post release and commit? It might lead to deviations

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

If I look at last v0.7.6 release, offline changelog was commited at 18:00, and release was done on 15:06. I see no deviation.

Copy link
Member

Choose a reason for hiding this comment

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

yeas, because offline changelog is the source for release text

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Is it worth to sacrafice automation in order to have "offline" change log?
you have two tags, and tool to work with those tags. ATM we run tool get output and paste it into "Release".
I propose to run tool as part of release draft pipeline to format a release. Then run tool with same input to commit post release offline changelog. Sorry I only see an improvement here.

Additionally draft can be changed the same way from "offline" changelog.

Copy link
Member

@ytsarev ytsarev Mar 2, 2021

Choose a reason for hiding this comment

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

I am not talking about sticking to current scenario, more thinking of avoiding pitfalls with the new one. Can we write to CHANGELOG.md in post-release pipeline and commit it automatically?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This option can be explored for sure.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@ytsarev ammended

Copy link
Member

Choose a reason for hiding this comment

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

@k0da very cool, thanks!

@k0da k0da force-pushed the releaser branch 2 times, most recently from 037ec14 to 88641c8 Compare March 2, 2021 19:56
publish:
runs-on: ubuntu-20.04
steps:
- uses: actions/checkout@v1
Copy link
Member

Choose a reason for hiding this comment

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

Please switch to v2

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done

@k0da
Copy link
Collaborator Author

k0da commented Mar 3, 2021

@k0da
Copy link
Collaborator Author

k0da commented Mar 3, 2021

IMO any way automated PR can be closed any time. So this is quite harmless improvement

@k0da k0da requested a review from ytsarev March 3, 2021 10:06
ytsarev
ytsarev previously approved these changes Mar 3, 2021
Copy link
Member

@ytsarev ytsarev left a comment

Choose a reason for hiding this comment

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

lgtm

somaritane
somaritane previously approved these changes Mar 3, 2021
Copy link
Contributor

@somaritane somaritane left a comment

Choose a reason for hiding this comment

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

lgtm, can't wait for new release :)🤞

* Adds separate Dockerfile for each architecture to keep base image
  unchanged.
* Brings github_changelog_generator into a release pipeline
* Add .goreleaser.yaml with go build and amd64/arm64 images with docker
  common manifest
* Introduce pipeline for tag event, where docker artifacts will be
  built.
* Rename helm pipeline (release) into helm_publish
* Opens pull-request with offline changelog (CHANGELOG.md) update

Signed-off-by: Dinar Valeev <dinar.valeev@absa.africa>
@k0da k0da dismissed stale reviews from somaritane and ytsarev via c90ee9d March 3, 2021 12:11
@k0da k0da requested review from somaritane and ytsarev March 3, 2021 12:13
@k0da
Copy link
Collaborator Author

k0da commented Mar 3, 2021

@somaritane @ytsarev I've ammended fetch-depth param to checkout action to preserve full history for github_changelog_generator

@k0da k0da merged commit e0a4333 into master Mar 3, 2021
@somaritane somaritane deleted the releaser branch March 9, 2021 20:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants