Enable goreleaser to release binaries #431
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪 |
Co-authored-by: Victor Martinez <victormartinezrubio@gmail.com>
|
I will experiment with Goreleaser once I merge this PR. |
| } | ||
| stage('Release') { | ||
| when { | ||
| tag pattern: '(v)?\\d+\\.\\d+\\.\\d+', comparator: 'REGEXP' |
There was a problem hiding this comment.
@mtojek have we thought about the versioning pattern or release cycles that elastic-package is going to follow?
I don't think it should follow semantic versioning. Any version of elastic-package should work with any supported package. If we introduce a breaking change in the spec, the spec should have some versioning so elastic-package can support both versions (as docker-compose does for example). Breaking changes in elastic-package should be considered as bugs. And I would prefer to don't have different release branches.
In any case, I shouldn't assume this pattern is for elastic versioning, it can also be v<year>.<month>.<revision>, I would like something like this for elastic-package. 🙂
There was a problem hiding this comment.
Frankly speaking, I like semantic versioning for every use case, as it allows for introducing potentially dangerous (breaking changes). We have dependabot, mergify, no goreleaser, which means that every new release can be automatically pulled in into elastic/integrations.
I don't think it should follow semantic versioning. Any version of elastic-package should work with any supported package. If we introduce a breaking change in the spec, the spec should have some versioning so elastic-package can support both versions (as docker-compose does for example).
I admit that we never followed this rule. I'm not sure if it's possible in real life without bumping version in package manifests (so far every package is 1.0.0). Many times there were cases in which we had to harden the spec validation (by introducing additional semantic validators) which obviously caused failures for packages. I agree we should bump up the spec version then, but I'm not sure about consequences across the entire platform (when format version changes - I know it shouldn't cause any problems).
In any case, I shouldn't assume this pattern is for elastic versioning, it can also be v.., I would like something like this for elastic-package. 🙂
I see we can mimic it with semver, although I admit I'm too much addicted to the natural semver form (major, minor, patch).
I'm happy to zoom about this next week if you prefer!
There was a problem hiding this comment.
Ok, we can think more about this, let's talk next week!
4 participants
This PR enables support for GoReleaser to release elastic-package distributions.
Issue: #32
How to trigger a release:
git tag -a v0.1.0 -m "First release" git push origin v0.1.0(source: Quick start)