Skip to content

Enable goreleaser to release binaries #431

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

Merged
merged 2 commits into from
Jul 16, 2021
Merged

Enable goreleaser to release binaries #431

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f939c34
Enable goreleaser to release binaries
Jul 16, 2021
7cb1223
Update .ci/Jenkinsfile
mtojek Jul 16, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions .ci/Jenkinsfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@ pipeline {
environment {
BASE_DIR="src/github.com/elastic/elastic-package"
JOB_GIT_CREDENTIALS = "f6c7695a-671e-4f4f-a331-acdce44ff9ba"
GITHUB_TOKEN_CREDENTIALS = "2a9602aa-ab9f-4e52-baf3-b71ca88469c7"
PIPELINE_LOG_LEVEL='INFO'
AWS_ACCOUNT_SECRET = 'secret/observability-team/ci/elastic-observability-aws-account-auth'
HOME = "${env.WORKSPACE}"
Expand Down Expand Up @@ -67,6 +68,16 @@ pipeline {
}
}
}
stage('Release') {
when {
tag pattern: '(v)?\\d+\\.\\d+\\.\\d+', comparator: 'REGEXP'
Copy link
Member

Choose a reason for hiding this comment

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

@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. 🙂

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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!

Copy link
Member

Choose a reason for hiding this comment

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

Ok, we can think more about this, let's talk next week!

}
steps {
withCredentials([string(credentialsId: "${GITHUB_TOKEN_CREDENTIALS}", variable: 'GITHUB_TOKEN')]) {
sh 'curl -sL https://git.io/goreleaser | bash'
}
}
}
}
post {
cleanup {
Expand Down