Skip to content

A first cut of automated releases using goreleaser#226

Closed
trishankatdatadog wants to merge 3 commits intomasterfrom
trishankatdatadog/goreleaser
Closed

A first cut of automated releases using goreleaser#226
trishankatdatadog wants to merge 3 commits intomasterfrom
trishankatdatadog/goreleaser

Conversation

@trishankatdatadog
Copy link
Copy Markdown
Contributor

@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
Copy Markdown

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
Copy Markdown
Contributor

rdimitrov commented Mar 1, 2022

@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
Copy Markdown
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
Copy Markdown
Contributor Author

trishankatdatadog commented Mar 1, 2022

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
Copy Markdown
Contributor Author

trishankatdatadog commented Mar 1, 2022

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
Copy Markdown
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!

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

@joshuagl joshuagl Mar 1, 2022

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
Copy Markdown
Contributor

rdimitrov commented Mar 2, 2022

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
Copy Markdown
Contributor Author

trishankatdatadog commented Mar 3, 2022

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
Copy Markdown
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
Copy Markdown
Contributor Author

trishankatdatadog commented Mar 3, 2022

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
Copy Markdown
Contributor Author

trishankatdatadog commented Mar 30, 2022

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