Automate binary releases

[vearutop]

Description

This PR adds GitHub Action to build and upload binary artifacts on release creation.
Also it arranges examples in a single module that references current godog, so that examples are always up to date with latest godog.

Motivation & context

Currently artifacts uploading is manual and makes releases more effortful than they should be.
With this automation we can reduce the burden for smaller releases and tag every meaningful change as soon as it is ready and PR is merged.

Type of change

• Refactoring/debt (improvement to code design or tooling without changing behaviour)

Note to other contributors

godog.Version is now populated from module info and does not need manual editing.

Update required of cucumber.io/docs

No update.

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• I have added tests to cover my changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

[codecov]

Codecov Report

Merging #437 (ed3a0a9) into main (1dcc44f) will increase coverage by 0.04%.
The diff coverage is 0.00%.

❗ Current head ed3a0a9 differs from pull request most recent head d1a48b0. Consider uploading reports for the commit d1a48b0 to get more accurate results

@@            Coverage Diff             @@
##             main     #437      +/-   ##
==========================================
+ Coverage   81.42%   81.46%   +0.04%     
==========================================
  Files          26       27       +1     
  Lines        2175     2180       +5     
==========================================
+ Hits         1771     1776       +5     
+ Misses        311      310       -1     
- Partials       93       94       +1     

Impacted Files	Coverage Δ
mod_version.go	0.00% <0.00%> (ø)
suite.go	87.85% <0.00%> (+1.52%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1dcc44f...d1a48b0. Read the comment docs.

[aslakhellesoy]

This looks great!

@mattwynne @aurelien-reeves let’s discuss this to make sure it’s aligned with the general release process that is described in https://github.com/cucumber/.github/blob/main/RELEASING.md

[mattwynne]

This looks great!

@mattwynne @aurelien-reeves let’s discuss this to make sure it’s aligned with the general release process that is described in https://github.com/cucumber/.github/blob/main/RELEASING.md

Sure, it looks good to me.

@vearutop did you consider using https://github.com/goreleaser/goreleaser?

[vearutop]

@aslakhellesoy I think godog deviates from RELEASING.md guidelines in a way that release/* branches are not used since v0.11.0 and also it seems there were no automations configured for these branches. We also don't backport features or fixes to older versions.

Collecting unreleased changes and then eventually (or periodically) releasing them seems unnecessary limiting for small self-contained changes, though it totally makes sense if multiple changes need to be shipped and tested together.

I think we can make patch version releases asap with only CHANGELOG.md updates, and prepare more documentation in release-notes for major releases (having breaking changes). Reducing release cycle (especially for bug fixes) may help with adoption and faster feedback.

@mattwynne I was conservatively thinking to make this with least changes and dependencies. We can upgrade to goreleaser, it has interesting additional features like brew formula management though I haven't used goreleaser in the past.

The approach from this PR was tested with some of my personal projects.

[vearutop]

It is difficult to test this with main repo before merge, but it worked ok in my fork: https://github.com/vearutop/godog/releases/tag/test-release-assets5.

[aslakhellesoy]

@aslakhellesoy I think godog deviates from RELEASING.md guidelines in a way that release/* branches are not used since v0.11.0 and also it seems there were no automations configured for these branches. We also don't backport features or fixes to older versions.

The reason we use release/* branches is purely to limit who can make a release. To do this we configure each repo so that only members of the @cucumber/release team can push to these branches. We have GitHub actions that are only triggered on a push to release/*, and also GitHub secrets that are only available to GitHub Actions on release/* branches.

The release/* branches in this release process should be thought of as ephemeral - they should ideally be removed after the release (we just haven't automated that part yet).

You can see how this is set up in the tag-expressions repo:

• https://github.com/cucumber/cucumber-expressions/settings/branches
• https://github.com/cucumber/cucumber-expressions/settings/environments/302175658/edit

[mattwynne]

I suggest we merge this, and we can deal with the other two suggestions (goreleaser, automation via release/* branches) as later iterations.

[mattwynne]

What's the new mod_version.go file for? Even though it's simple it's not covered by tests - should we add a unit test for it?

[vearutop]

mod_version.go is version info initializer that leverages Go Module information that is injected during the build. It is a separate file to only compile with go1.12 or later. It works somewhat similar to LDFLAGS, but automatically. When user runs go install github.com/cucumber/godog/cmd/godog@latest, Version value will be populated with actual version used in the build (e.g. v0.12.3).

For example you can install godog from this branch and it will have version (module pseudo version in this case) available.

go install github.com/cucumber/godog/cmd/godog@release-assets
go: downloading github.com/cucumber/godog v0.12.3-0.20211117010138-3de43dc834a3

godog --version
Godog version is: v0.12.3-0.20211117010138-3de43dc834a3

We can remove build tags and move the contents to an existing file given that go1.11 is very old and is not supported anyway. Should I do it?

I'll add a unit test for this file to improve coverage.
It turned out module information is not populated during tests, only during build, so it is not easy to cover it.