Allow arch to be set in manifest for when pushing packages

[radiosilence]

So this may require a bit more discussion. This PR basically allows you to set an Arch variable in the package.manifest as part of your build process, so you can package for multiple architectures as part of your CI builds.

However, I am not sure the mechanism for picking the architecture for when you are running the packages, and also I get errors with it not being able to find an arm64 kernel: error: /Users/jc/.ops/0.1.50-arm/kernel.img: stat /Users/jc/.ops/0.1.50-arm/kernel.img: no such file or directory) when trying to build a derivative image.

Other issue is that for GOARCH you use arm64, and it seems like in ops x86_64 is used so needs to be some switching around there.

[eyberg]

so there's a few things:

ops will default to whatever arch you are on (so if on x86_64 it defaults to that; if on arm64 it defaults to that (such as mac m1/m2/m3)

however, you can also override it for many commands by tacking '--arch' such as

ops pkg search --arch=arm64 redis
ops pkg search --arch=amd64 redis

in your case you prob. don't have an arm build:

ops update --arm

because of how things evolved the repo does use 'x86_64' (like aws/proxmox providers, qemu) use rather than go-style 'amd64' and so there is code inside ops to switch that around when talking to that api (but we can add support on that end to translate to accept both for now)

[radiosilence]

Ok cool! So in CI if I'm building an image based on a package, should I run ops update --arch first to select the package arch for the image I'm building?

Basically my personal site I'd like to be able to build AMIs for both Gravitron and normal instances, and for my package nano-web I'd like my CI pipeline to spit out packages for both arch.

[eyberg]

ops update --arch

merely downloads or updates an exiting arm nanos version - it's independent from building an image

if you're building from a package and you want use a diff. architecture you'd do something like:

ops image create --arch=amd64 --package user/pkg:0.0.1

or

ops image create --arch=arm64 --package user/pkg:0.0.1

packages themselves don't encode arch information (today) - you just need to know which pkg is what arch binaries when passing to 'image create' or 'pkg load' - and you'll need 2 separate ones

[eyberg]

sorry, coming back to this, for your use-case in particular - just setting the arch when uploading to the repo - I think for now if you keep that arch you added in

https://github.com/nanovms/ops/blob/aaadead497276455d7a6d4c85427445f492649e7/lepton/push.go#L29 is fine

then to set it - you don't need it in Config because this gets marshalled into a lepton.Package

I think if that works for you that would be fine w/us for now

there is more work to do here but that can be done in other prs (and some of it we're going to have to do ourselves)

1) x86_64 vs amd64 - right now repo.ops.city only expects 'x86_64' or 'arm64' so either set that in your manifest or include code to switch 'amd64' to 'x86_64' to that before uploading; (I think it does make sense to encode this metadata inside of a pkg cause otherwise you have to run file or something the binary itself to really know which is not ideal)

2) this shares a diff. known issue - while the repo can diff. between packages with the same user, same name, same version but diff. architecture - ops currently can not; w/nanos we've been tacking on '-arm' extensions to the folders; either that needs to be done or we just put the arm ones in a diff. subfolder like ~/.ops/package/arm/' or something - I think (for now) it probably makes the most sense to do the latter since I really don't want to mass update all the old packages; let me think about this more and I might address this particular issue

[eyberg]

https://github.com/nanovms/ops/pull/1611

[eyberg]

i added this in https://github.com/nanovms/ops/pull/1611 which allows the same pkg name/version but diff arch locally