Skip to content

Update magefile/mage to v1.8.0#9769

Merged
andrewkroh merged 2 commits intoelastic:masterfrom
andrewkroh:feature/update-mage-version-1-8-0
Jan 2, 2019
Merged

Update magefile/mage to v1.8.0#9769
andrewkroh merged 2 commits intoelastic:masterfrom
andrewkroh:feature/update-mage-version-1-8-0

Conversation

@andrewkroh
Copy link
Member

@andrewkroh andrewkroh commented Dec 22, 2018

Vendor github.com/magefile/mage version v1.8.0 (aedfce64c122eef47009b7f80c9771044753215d).

I updated the make mage target to detect the mage version and automatically upgrade

Upgrade benefits:

  • mage will automatically detect changes in dependencies of magefile.go because it always recompiles the magefile.go on Go 1.11. This feature relies on the GOCACHE to mitigate the expense of recompiling each time. It’s a little slower but more reliable.
  • We can start to DRY out the magefiles because this version has support for target imports. It’s a simple Go import statement annotated with // mage:import [namespace].

TODO:

  • Test behavior when moving between branches. We’ll likely need to backport make logic to re-install mage if the version is wrong (e.g. downgrade automatically).
    • The only thing that's not backwards compatible with the new mage version is executing package on non-Linux. This is because the new mage version added -goos and -goarch flags for use with -compile and no longer honors the GOOS and GOARCH when pre-compiling a mage binary that targets Linux for use inside the container.

Vendor github.com/magefile/mage version v1.8.0 (aedfce64c122eef47009b7f80c9771044753215d).
@andrewkroh andrewkroh added the in progress Pull request is currently in progress. label Dec 22, 2018
@andrewkroh andrewkroh requested a review from a team as a code owner December 22, 2018 02:53
This was a work-around I added, but now mage has first class support for this.
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.

Could we potentially backport this to 6.x as I expect most development will happen now in 6.x and master. So change of branch should become less of a problem?

@andrewkroh andrewkroh added review and removed in progress Pull request is currently in progress. labels Dec 28, 2018
@andrewkroh andrewkroh merged commit b18299a into elastic:master Jan 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants