getporter / operator

The Porter Operator gives you a native, integrated experience for managing your bundles from Kubernetes. It is the recommended way to automate your bundle pipeline with support for GitOps.
https://porter.sh/operator
Apache License 2.0
31 stars 19 forks source link

`mage build` overwrites ARM binary #105

Open donmstewart opened 2 years ago

donmstewart commented 2 years ago

Recompiling the porter binary for arm on Apple M1 works fine but building the operator has an issue where it looks like it somehow overwrites the binary on each invocation with an amd64 version.

Example:

# Copy the porter cli arm binary over the amd64 version in the porter operator directory

~/Dev/go/sr/g/g/operator cp /Users/donstewart/.porter/porter  /Users/donstewart/Development/go/src/github.com/getporter/operator/bin/

# Get the version of binary
~/Dev/go/sr/g/g/operator Users/donstewart/Development/go/src/github.com/getporter/operator/bin/porter version
porter v1.0.0-beta.1-13-g0cab1b78 (0cab1b78)

# run the mage build of the operator
~/Dev/go/sr/g/g/operator mage build                                                                  
panic: failed to run "/Users/donstewart/Development/go/src/github.com/getporter/operator/bin/porter plugin install kubernetes --version latest --feed-url=https://cdn.porter.sh/plugins/atom.xml: fork/exec /Users/donstewart/Development/go/src/github.com/getporter/operator/bin/porter: bad CPU type in executable"

goroutine 24 [running]:
github.com/carolynvs/magex/mgx.Must({0x10387df78?, 0x140003fe360?})
    /Users/donstewart/go/pkg/mod/github.com/carolynvs/magex@v0.8.1/mgx/must.go:8 +0xd4
github.com/carolynvs/magex/shx.PreparedCommand.Exec({0x14000576160?, 0x2c?})
    /Users/donstewart/go/pkg/mod/github.com/carolynvs/magex@v0.8.1/shx/prepared_command.go:131 +0x280
github.com/carolynvs/magex/shx.PreparedCommand.Run({0x14000576160?, 0x6?})
    /Users/donstewart/go/pkg/mod/github.com/carolynvs/magex@v0.8.1/shx/prepared_command.go:147 +0xa4
main.getPlugins.func1()
    /Users/donstewart/Development/go/src/github.com/getporter/operator/magefiles/magefile.go:188 +0x194
golang.org/x/sync/errgroup.(*Group).Go.func1()
    /Users/donstewart/go/pkg/mod/golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:57 +0x64
created by golang.org/x/sync/errgroup.(*Group).Go
    /Users/donstewart/go/pkg/mod/golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c/errgroup/errgroup.go:54 +0x90

# recheck the version of the porter cli binary in the porter operator  directory
~/Dev/go/sr/g/g/operator/Users/donstewart/Development/go/src/github.com/getporter/operator/bin/porter version
zsh: bad CPU type in executable: /Users/donstewart/Development/go/src/github.com/getporter/operator/bin/porter

It also looks like it is doing this when installing the mixins from the repositories which I also do not want it to do as I have compiled arm versions locally which are in my .porter/mixins directory.

I am trying to build the operator so I can debug #106

carolynvs commented 2 years ago

Yup not ideal. I have been working on an m1 for a while and haven't needed to recompile porter to arm64. Was there a specific problem that prompted you to recompile vs using the mixins and porter binaries that the magefile downloads? On linux arm64, I understand the problem but on a mac m1, I'm seeing rosetta work just fine to run the amd64 binaries.

donmstewart commented 1 year ago

No Rosetta installed on my end.

I created these opportunities for myself with my conscious choice not to go the Rosetta route and take the pain now so if/when Apple decide to pull it from the OS I don't have a mad scramble.

That said ARM (Graviton2 etc.) is becoming a thing for us in the data centre too. So also working to support that.

carolynvs commented 1 year ago

A lot of the inertia around having porter, plugins and mixins support arm is that we need a design for how CNAB bundles should deal with targeting multiple environments, and how that will be supported during porter build. I'll dig through our issue backlog (and CNAB's) to see what's been thought about so far and we can resurrect those conversations.

VinozzZ commented 1 year ago

related porter issue: https://github.com/getporter/porter/issues/2021

carolynvs commented 1 year ago

@donmstewart Sorry this fell through the cracks! If you are still dealing with this problem, here's one workaround: make sure that the version you compiled of porter matches the version that porter's magefile is expecting. When they don't match, the magefile downloads the binary and overwrites it.

So when you compile porter, set the version in one of 3 ways (your pick):

  1. tag the commit and use mage build
  2. edit pkg/version.go and set the values in code, then build with go build
  3. pass the version to go build with ldflags -w -X get.porter.sh/porter/pkg.Version=VERSION

Then copy over both the porter client AND the porter-runtime into the bin (it goes to runtimes/porter-runtime).

As long as the magefile can run porter version and get back what it expects, it won't overwrite them.