Add a mechanism to detect other platforms to build

[stackedsax]

I wanted to build armadactl on my Mac laptop, so I added a section of containerd's Makefile to set GOOS and GOARCH parameters. I could add in support for even more ornate flavors of platforms if we think it's useful or slim this down if we think it's too verbose.

I also fixed a tiny typo in the gobuild line. GARCH should have been GOARCH.

[jankaspar]

Thanks Alex, we just need to think this through, the linux is hard coded because executor & server are build into docker images, the makefile is used on ci/cd.

It would be better to make additional target for local development without any flags to build for local system.

It could be also useful to build armadactl for multiple platforms on ci/cd, so we can provide it for download.

[stackedsax]

Thanks Alex, we just need to think this through

Agreed. I kinda threw this up there to have the discussion :D

It would be better to make additional target for local development without any flags to build for local system.

Yep, this would have worked for me, too.

the linux is hard coded because executor & server are build into docker images, the makefile is used on ci/cd.
It could be also useful to build armadactl for multiple platforms on ci/cd, so we can provide it for download.

To address both of these at once, is your thought to:

• cross-compile for multiple platforms as part of CI
• in the Dockerfile just COPY the correct binary into the container?

[stackedsax]

I feel like @itamarst might have some input here.

[itamarst]

In the broadest terms, for release purposes you'd want to:

1. Build user-facing CLIs for Mac/Linux/maybe even Windows in CI (Azure Pipelines is good if you decide on all 3), and put them somewhere downloadable, especially releases.
2. Have the CLI do a version check (which users can disable), so it can say "oh, you're out of date, you should update".
3. Distribute CLI via means that allow for automatic updates, depending on expected user base (e.g. if you expect Brew users, Homebrew for Mac, and then either Snap/Flatpak for Linux users or Deb/RPM channels).

2 and 3 are somewhat alternatives, but much better to do both. And you can't really skip doing at least one of them, otherwise you end up with users never updating which can be a significant maintenance burden later on... and/or cause users to give up because "it's broken!" when really it's "you're using an ancient and buggy version but you can't tell".

For development purposes, there are probably multiple use cases:

1. Build CLI for local platform.
2. Build Docker image for server.
3. Run tests, ideally on local platform but might be better in Docker, depending.
4. Build server without Docker image, for some form of manual testing.

So a good starting point might be having two variants of build: "build happens inside Docker image" (implicitly always targeting Linux) and "build happens on local OS".

[jankaspar]

Hi, thanks for the suggestions, it is all reasonable, but I think we are just not yet at the point to do all of this.

As a first step I think we need to provide as easy as possible local development build so people can quickly start with the project.

Anyway happy to accept PRs or raised issues for backlog.

[jankaspar]

I have updated makefile in #175 to make local build work.
Opening #176 and #177 to track other changes.