Skip to content
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.

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

Use .go-version to specify the Go version for all CI builds #4303

Merged
merged 1 commit into from
May 13, 2017

Conversation

andrewkroh
Copy link
Member

Having a simple file that requires no parsing to retrieve the Go version
provides us a standard portable way to know what Go version to use for builds.
It's basically the least common denominator for builds accross CI systems
(Jenkins, AppVeyor, Travis) and operating systems.

Also changed AppVeyor to invalidate the cached Go version only when the
.go-version file changes instead of when the .appveyor.yml changes.

Having a simple file that requires no parsing to retrieve the Go version
provides us a standard portable way to know what Go version to use for builds.
It's basically the least common denominator for builds accross CI systems
(Jenkins, AppVeyor, Travis) and operating systems.

Also changed AppVeyor to invalidate the cached Go version only when the
.go-version file changes instead of when the .appveyor.yml changes.
Copy link
Contributor

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

I was hoping to have a file like .beat.yml or something like that in the future which contains go version, beat version etc. But yaml doesn't work well with shell scripts. This is a nice and simple solution.

@ruflin
Copy link
Contributor

ruflin commented May 12, 2017

WFG

@ruflin ruflin merged commit 795ceab into elastic:master May 13, 2017
andrewkroh added a commit to andrewkroh/beats that referenced this pull request May 13, 2017
…4303)

Having a simple file that requires no parsing to retrieve the Go version
provides us a standard portable way to know what Go version to use for builds.
It's basically the least common denominator for builds accross CI systems
(Jenkins, AppVeyor, Travis) and operating systems.

Also changed AppVeyor to invalidate the cached Go version only when the
.go-version file changes instead of when the .appveyor.yml changes.
ruflin pushed a commit that referenced this pull request May 13, 2017
…4307)

Having a simple file that requires no parsing to retrieve the Go version
provides us a standard portable way to know what Go version to use for builds.
It's basically the least common denominator for builds accross CI systems
(Jenkins, AppVeyor, Travis) and operating systems.

Also changed AppVeyor to invalidate the cached Go version only when the
.go-version file changes instead of when the .appveyor.yml changes.
andrewkroh added a commit to andrewkroh/beats that referenced this pull request May 26, 2017
…4303)

Having a simple file that requires no parsing to retrieve the Go version
provides us a standard portable way to know what Go version to use for builds.
It's basically the least common denominator for builds accross CI systems
(Jenkins, AppVeyor, Travis) and operating systems.

Also changed AppVeyor to invalidate the cached Go version only when the
.go-version file changes instead of when the .appveyor.yml changes.
(cherry picked from commit 795ceab)
tsg pushed a commit that referenced this pull request May 29, 2017
…4403)

Having a simple file that requires no parsing to retrieve the Go version
provides us a standard portable way to know what Go version to use for builds.
It's basically the least common denominator for builds accross CI systems
(Jenkins, AppVeyor, Travis) and operating systems.

Also changed AppVeyor to invalidate the cached Go version only when the
.go-version file changes instead of when the .appveyor.yml changes.
(cherry picked from commit 795ceab)
@andrewkroh andrewkroh deleted the feature/go-version-file branch July 5, 2017 22:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants