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.

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

Jump to bottom

A first cut of automated releases using goreleaser #226

Closed
wants to merge 3 commits into from
Closed

A first cut of automated releases using goreleaser #226

wants to merge 3 commits into from

Conversation

trishankatdatadog
Copy link
Member

@trishankatdatadog trishankatdatadog commented Feb 24, 2022 •
edited
Loading

Thanks to #157 for inspiration (dropped SBOMs and signing now for simplicity).

Checklist:

  • Release client vs all
  • Changelog (including a convention for marking PRs with backwards-incompatible changes)
  • Prereleases
  • Define convention to mark backwards-incompatible changes (despite using a MAJOR SemVer version of 0)
  • Test with pushing a tag

Deferred:

  • SBOMs
  • Sign and add to Sigstore (besides gosumdb)

shibumi and others added 3 commits February 23, 2022 22:40
@shibumi @trishankatdatadog
task: add goreleaser + cosign releases
4efc6e4
@shibumi @trishankatdatadog
feat: keyless realeases with goreleaser and cosign
c4d49cf 
This commit enables keyless signatures via the Github Actions workload identity. The pipeline will run on a new tag and will generate a compiled cli and server version of TUF and a signed source tarball. The keys are ephemeral and valid for 30min and strictly coupled to the workload identity of the Github Actions workflow. Transparency logs will be automatically uploaded to the public rekor instance
@trishankatdatadog
try a basic config of gorelease
44cbc90
@coveralls
Copy link

coveralls commented Feb 24, 2022 •
edited
Loading

Pull Request Test Coverage Report for Build 1891098152

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 70.23%
Totals Coverage Status
Change from base Build 1831480097: 0.0%
Covered Lines: 2168
Relevant Lines: 3087
💛 - Coveralls

@rdimitrov
Copy link
Contributor

@trishankatdatadog: Thanks again for working on that! 🥳

About the 2nd point, Changelog, does what we have in #215 cover what you have in mind for stating any incompatible changes in the PR description or we need something more detailed?

@joshuagl
Copy link
Member

joshuagl commented Mar 1, 2022 •
edited
Loading

Thank you for working on this! Which of the checklist items must happen before we merge this PR, and which can be filed as separate issues?

Do we need to tag current state before we merge this, so that there's a baseline to compare against?

  • Prereleases

Can you expand on this a bit? Is the goal to be able to make pre-releases with a tagging convention?

  • Define convention to mark backwards-incompatible changes (despite using a MAJOR SemVer version of 0)

Isn't SemVer the convention, i.e., we have not made a commitment to any kind of stable API. We aim to highlight backwards incompatible changes in the Changlog, but until such a time as we make a 1.0 release those changes may happen at any arbitrary release.

  • Test with pushing a tag

We can/should test on a personal fork.

@trishankatdatadog
Copy link
Member Author

About the 2nd point, Changelog, does what we have in #215 cover what you have in mind for stating any incompatible changes in the PR description or we need something more detailed?

I suppose it does if every PR's description in its entirety is copied into the changelog, no?

@trishankatdatadog
Copy link
Member Author

Do we need to tag current state before we merge this, so that there's a baseline to compare against?

Yes we should

Can you expand on this a bit? Is the goal to be able to make pre-releases with a tagging convention?

Yes

Isn't SemVer the convention, i.e., we have not made a commitment to any kind of stable API. We aim to highlight backwards incompatible changes in the Changlog, but until such a time as we make a 1.0 release those changes may happen at any arbitrary release.

The last bit must have slipped my mind. So, perfect, we can stick to 0.MINOR.PATCH for now and still make breaking releases

We can/should test on a personal fork.

👍🏽

So are we nearly done here?

joshuagl
joshuagl reviewed Mar 1, 2022
View reviewed changes
Copy link
Member

@joshuagl joshuagl left a comment

Choose a reason for hiding this comment

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

I think we're nearly done here. Someone (happy to do it Thursday/Friday if no one else volunteers) should tag the current state (as 0.1.0 or some other version?) and then we can merge this.

cc @theupdateframework/go-tuf-maintainers please take a look!

.github/workflows/release.yml
contents: write
runs-on: ubuntu-latest
needs: test
if: github.event_name == 'push' && contains(github.ref, 'refs/tags/')
Copy link
Member

Choose a reason for hiding this comment

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

Nit: might be simpler to have this in a separate workflow with on: push: tags?

@rdimitrov
Copy link
Contributor

About the 2nd point, Changelog, does what we have in #215 cover what you have in mind for stating any incompatible changes in the PR description or we need something more detailed?

I suppose it does if every PR's description in its entirety is copied into the changelog, no?

@trishankatdatadog - Oh, I see. Well, from what I found goreleaser uses only the commit messages. There's this too - buchanae/github-release-notes, which can replace the commit messages with PR titles instead, but it still doesn't solve our goal.

A possible solution is to leverage the groups feature for composing the changelog. If we enforce people to use a dedicated tag word/phrase in their commit message when there's a breaking change, this will be caught up by goreleaser and will create a dedicated section in the changelog with all commits that supposedly introduce breaking changes.

@trishankatdatadog
Copy link
Member Author

Ok, sounds good. @joshuagl @rdimitrov can you both pls help finish this PR? I'm afraid I don't have the time this week or the next...

@joshuagl
Copy link
Member

joshuagl commented Mar 3, 2022

I just tagged v0.1.0. @rdimitrov and/or myself will finish up this PR early next week.

@trishankatdatadog
Copy link
Member Author

Note: @developer-guy reached out to help, but he doesn't have collaborator access to this repo. It's ok, Joshua and Radoslav can take over. Thanks, everyone!

@rdimitrov rdimitrov mentioned this pull request Mar 15, 2022
Merged
@trishankatdatadog
Copy link
Member Author

Closed by #234

@trishankatdatadog trishankatdatadog deleted the trishankatdatadog/goreleaser branch March 30, 2022 13:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@joshuagl joshuagl joshuagl left review comments

@mnm678 mnm678 mnm678 approved these changes

@asraa asraa Awaiting requested review from asraa

@ethan-lowman-dd ethan-lowman-dd Awaiting requested review from ethan-lowman-dd

Assignees

@rdimitrov rdimitrov

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
6 participants
@trishankatdatadog @coveralls @rdimitrov @joshuagl @mnm678 @shibumi