Proposal: Alternative way to package semantic-release

[cliedeman]

This is a spike to test an alternative way to package semantic-release.

I have an example repo here with https://github.com/cliedeman/go-semantic-release-example/blob/master/main.go and a sample pr to do the bare minimum amount of work to test the concept - https://github.com/go-semantic-release/semantic-release/pull/87

The idea is that we provide an alternative way to create a semantic object and manually populate the plugins.

Pros:

• Only uses go.mod, can integrate easily with tools like renovate to stay up to date
• Testing is easier. Can run like a standard go project, this should make e2e tests a lot easier too
• We could test against a mock provider that returns a canned set of commits and tags
• Easier to build a customized docker image fit for purposed
• Can easily integrate a custom plugin/hooks without pubishing a plugin

Cons

• Extra entrypoints in semantic-release core
• Initializing the plugins is somewhat awkward because they accept map[string]string

[christophwitzko]

Hey @cliedeman, packaging semantic-release can be done by creating a zip/tar of the .semrel directory and the go-semantic-release binary. Terraform does it the same way: https://github.com/hashicorp/terraform/tree/master/tools/terraform-bundle

I personally would not prefer to build a single semantic-release binary. The current plugin discovery already supports an easy way to customize / exchange plugins. The just need to be placed in the respective directory. For example .semrel/darwin_amd64/hooks-test/1.0.0/my-custom-hooks-bin will be used if --hooks test is set.