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

Add goreleaser #115

Merged
merged 14 commits into from
Jan 11, 2022
Merged

Add goreleaser #115

merged 14 commits into from
Jan 11, 2022

Conversation

josvazg
Copy link
Contributor

@josvazg josvazg commented Dec 13, 2021

Add goreleaser to a release GitHub action and disable versioning and release code from runway CI.

Tested on a separate repo to check out how releases would look like in the GitHub releases page.

@josvazg josvazg self-assigned this Dec 13, 2021
@josvazg josvazg marked this pull request as draft December 13, 2021 11:22
@josvazg
Copy link
Contributor Author

josvazg commented Dec 13, 2021

Keeps failing, not sure I can reproduce locally. Debugging...

@josvazg
Copy link
Contributor Author

josvazg commented Dec 14, 2021

@tompizmor any clues on how can I void this stuttering?

binary=/home/runner/work/asset-relocation-tool-for-kubernetes/asset-relocation-tool-for-kubernetes/dist/asset-relocation-tool-for-kubernetes_darwin_arm64/relok8s

I'd rather have something like this:

binary=/home/runner/work/asset-relocation-tool-for-kubernetes/asset-relocation-tool-for-kubernetes/dist/relok8s_darwin_arm64/relok8s

Maybe I should fork this on my own repo to see how releases would look like in github before we merge in main. To avoid suprises.

@josvazg
Copy link
Contributor Author

josvazg commented Dec 15, 2021

BTW I branched this on my own private repo and I am playing with generating releases there, see how they look, if they autocreate tags, etc

.github/workflows/golangci-lint.yml Outdated Show resolved Hide resolved
@josvazg
Copy link
Contributor Author

josvazg commented Dec 15, 2021

Now I am blocked on how to make the version setting automation work well with tags. I was thinking we could remove the version file and list the last tag from git tag, but it does not seem so easy...

@josvazg
Copy link
Contributor Author

josvazg commented Dec 15, 2021

Sample releases on my repo tests:
Screenshot from 2021-12-15 20-05-20
Screenshot from 2021-12-15 20-06-29

@vmwclabot
Copy link

@josvazg, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding Signed-off-by: John Doe <[email protected]> to the last line of each Git commit message. The e-mail address used to sign must match the e-mail address of the Git author. Click here to view the Developer Certificate of Origin agreement.

@vmwclabot
Copy link

@josvazg, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding Signed-off-by: John Doe <[email protected]> to the last line of each Git commit message. The e-mail address used to sign must match the e-mail address of the Git author. Click here to view the Developer Certificate of Origin agreement.

@josvazg josvazg linked an issue Dec 16, 2021 that may be closed by this pull request
@tompizmor
Copy link
Member

tompizmor commented Dec 16, 2021

Now I am blocked on how to make the version setting automation work well with tags. I was thinking we could remove the version file and list the last tag from git tag, but it does not seem so easy...

Can't you use ldflags to set the version of the variable as it is done in charts-syncer?

.goreleaser.yml Outdated Show resolved Hide resolved
@tompizmor
Copy link
Member

@tompizmor any clues on how can I void this stuttering?

binary=/home/runner/work/asset-relocation-tool-for-kubernetes/asset-relocation-tool-for-kubernetes/dist/asset-relocation-tool-for-kubernetes_darwin_arm64/relok8s

I'd rather have something like this:

binary=/home/runner/work/asset-relocation-tool-for-kubernetes/asset-relocation-tool-for-kubernetes/dist/relok8s_darwin_arm64/relok8s

Maybe I should fork this on my own repo to see how releases would look like in github before we merge in main. To avoid suprises.

did you solve this already? actually I don't know where those paths are defined so I would need to check the documentation

@vmwclabot
Copy link

@josvazg, you must sign every commit in this pull request acknowledging our Developer Certificate of Origin before your changes are merged. This can be done by adding Signed-off-by: John Doe <[email protected]> to the last line of each Git commit message. The e-mail address used to sign must match the e-mail address of the Git author. Click here to view the Developer Certificate of Origin agreement.

@josvazg
Copy link
Contributor Author

josvazg commented Dec 17, 2021

Now I am blocked on how to make the version setting automation work well with tags. I was thinking we could remove the version file and list the last tag from git tag, but it does not seem so easy...

Can't you use ldflags to set the version of the variable as it is done in charts-syncer?

Yes, relok8s was using that already for setting the version inside the binary. The problem was that we were using a version file to track the version and fill ldflags, while goreleaser uses the tag. I tried to get rid of the version file, but it was problematic as I could not get a reliable last tag from git.
In the end I decided to keep the version file, so the version bumper script does the following:

  1. Read the current version file to get the previous version.
  2. Compile and run next-semver to:
  • Bump the version automatically, if the script was passed no arguments.
  • Or pass the user desired new version to use. The next-semver will complain if the desired version is not SemVer compliant or is considered before the previous version.
  1. Update the version file with the new version.
  2. Commit the version bump.
  3. Git tag and push the new version as "v${version}".

I think this should work for us to have manual decided releases.

@josvazg
Copy link
Contributor Author

josvazg commented Dec 17, 2021

BTW I noticed that there is something wrong with the ldflags trick here, I am passing the VERSION env var to goreleaser and this is supposedly using make to build the images, so that VERSION should be used to set the binary version with the ldflags, but it is NOT doing it for some reason, I still get the dev version.

And this is a PITA to test, as I need to do it on a separate private repo, to avoid polluting our releases here.

@josvazg
Copy link
Contributor Author

josvazg commented Dec 17, 2021

did you solve this already? actually I don't know where those paths are defined so I would need to check the documentation

Looking at the final release, those paths do not really matter. Only the files are listed, like in the images I pasted. So I think I will not try to fix any of that.

Jose Luis Vazquez Gonzalez added 2 commits January 10, 2022 12:26
Signed-off-by: Jose Luis Vazquez Gonzalez <[email protected]>
Signed-off-by: Jose Luis Vazquez Gonzalez <[email protected]>
Signed-off-by: Jose Luis Vazquez Gonzalez <[email protected]>
@josvazg
Copy link
Contributor Author

josvazg commented Jan 10, 2022

@petewall I tried to remove the CI code that handles and auto-bumps the version in commit 78c50a1
I most likely butchered the whole thing, so any help with that part would be appreciated.

.goreleaser.yml Outdated
@@ -0,0 +1,35 @@
# Make sure to check the documentation at https://goreleaser.com
before:
hooks:
Copy link
Contributor

Choose a reason for hiding this comment

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

This does not look right. Are we also building the binary in the hook? What for?

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 can try to remove. It will probably work anyways.
Seems goreleaser builds the binaries itself, does not like to rely on makefiles or anything.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

.goreleaser.yml Outdated
- -X github.com/vmware-tanzu/asset-relocation-tool-for-kubernetes/cmd.Version={{ .Version }}
goos:
- linux
- windows
Copy link
Contributor

Choose a reason for hiding this comment

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

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 can remove

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

.gitignore Outdated
@@ -8,3 +8,5 @@ build/*
.idea
*.iml


Copy link
Contributor

Choose a reason for hiding this comment

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

add a comment indicating that this is a directory of releases

# Releases

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

bump-version.sh Outdated
@@ -0,0 +1,15 @@
#!/bin/bash
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I guess we need to trust the operator that it's tagging a proper, valid version. We could also create the release a draft so it can be manually checked before releasing.

In any case, I kind of like how Kubeapps suggests to use some tooling to come up with a valid version, it's better than nothing. https://github.com/kubeapps/kubeapps/blob/master/docs/developer/release-process.md#2---create-a-git-tag

in following patches we should document our release process since now it has a manual component.

Copy link
Contributor

@migmartri migmartri left a comment

Choose a reason for hiding this comment

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

Accepted although ptal at removing windows support and some other pieces of feedback. Thanks!

.goreleaser.yml Outdated
binary: relok8s
archives:
- replacements:
darwin: Darwin
Copy link
Contributor

Choose a reason for hiding this comment

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

this replacements to add capitalization does not feel right, in fact I do not like the filename resulting of it which uses underscore + Capitalized at the same time.

To me the only two replacements here should be the ones related to the arch

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

Jose Luis Vazquez Gonzalez added 5 commits January 10, 2022 16:45
Signed-off-by: Jose Luis Vazquez Gonzalez <[email protected]>
Signed-off-by: Jose Luis Vazquez Gonzalez <[email protected]>
Signed-off-by: Jose Luis Vazquez Gonzalez <[email protected]>
Signed-off-by: Jose Luis Vazquez Gonzalez <[email protected]>
Signed-off-by: Jose Luis Vazquez Gonzalez <[email protected]>
@josvazg josvazg requested review from tompizmor and petewall January 10, 2022 15:53
Copy link
Contributor

@migmartri migmartri left a comment

Choose a reason for hiding this comment

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

From a quick check on the current pipeline and taking into account what in my opinion is the end goal (migrate to public CI), in this patch I think we are missing

  • Update build job to just build the docker image. In this case it might not make sense to build binaries since it has been delegated to goreleaser.
  • Update build job to stop writing the version file and releasing to github
    image

I think we also need to revisit that last relocate-chart job since it's weird that it's not part of the external tests that we already have.

.goreleaser.yml Outdated Show resolved Hide resolved
ci/pipeline.yaml Outdated Show resolved Hide resolved
@petewall
Copy link
Contributor

petewall commented Jan 10, 2022

I'll take a peek at the concourse pipeline. Just to make sure I'm tracking the changes, what we want to do going forward is:

  • On every commit and on every PR:

    • run the source test suite
  • On every new docker image from the registry:

    • run the relocate-chart job

The reason I like keeping the relocate-chart job is not because it's adding anything to the other test suite, but because it's an easy demo example of using relok8s in a concourse pipeline.

@josvazg
Copy link
Contributor Author

josvazg commented Jan 11, 2022

@migmartri yep that sounds reasonable, I will try to figure out the mapping between the pipeline graph and the yaml to make that happen.

@petewall yes, the idea for me is to remove in this PR anything from the CI code that we have moved to goreleaser & actions: build binaries and release, just as Miguel was mentioning. The rest can stay for now.

@josvazg
Copy link
Contributor Author

josvazg commented Jan 11, 2022

BTW I am seeing a new transient issue in tests:

--- FAIL: TestGroupChangesByChart (0.00s)
panic: runtime error: index out of range [0] with length 0 [recovered]
	panic: runtime error: index out of range [0] with length 0

It happens sometimes, maybe it is a race condition?

@josvazg
Copy link
Contributor Author

josvazg commented Jan 11, 2022

Just noticed that @petewall did the CI changes already.

Jose Luis Vazquez Gonzalez added 2 commits January 11, 2022 09:33
Signed-off-by: Jose Luis Vazquez Gonzalez <[email protected]>
Signed-off-by: Jose Luis Vazquez Gonzalez <[email protected]>
@josvazg
Copy link
Contributor Author

josvazg commented Jan 11, 2022

I added docs and fixed the latest cmment by @migmartri . As @petewall has fixed the CI pipeline, we can now mark this as ready to review.

@josvazg josvazg marked this pull request as ready for review January 11, 2022 08:38
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.

Releases management
6 participants