-
Notifications
You must be signed in to change notification settings - Fork 164
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
fix: Migrate release process to github actions #135
Conversation
I think that's a reasonable default and perhaps a flag to use the latest image might also be ok. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Dale!
b469d79
to
400eb18
Compare
400eb18
to
e40f246
Compare
This completely replaces the existing Travis-based scripts with Github Actions. - Images now built by CI will receive a docker tag corresponding to their git tag - Go release is called when any tag is pushed, which will use Github Actions to create the Github Release, and uploads cross-compiled Go binaries to it.
e40f246
to
221aa46
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
n-th approval! 🤣
This finishes up the work on #132, and is a re-do of #134
This completely replaces the existing Travis-based scripts with Github Actions.
to create the Github Release, and uploads cross-compiled Go binaries to it.
In addition, the current process is generic enough to run on any personal fork also, making it trivial for others to deploy their own kubectl-trace should they desire to.
Here is a sample test release created by this on my own fork:
https://github.com/dalehamel/kubectl-trace/releases/tag/v0.1.1-pre3
While this does add git tags to the docker images, I think we still need a way to set what default image to use, probably via another LDFlag, like we do in the tests. We can follow up with this in another PR, as I think @fntlnz and @zqureshi have already discussed this. I think a good default behavior would just be to default to a version tag the same as the binary version, as that should already be pushed by the changes in this PR.