Adding s390x to build workflow and makefile

[agracey]

I can't run this on my Github org due to not having a runner set up. Opening the PR as draft to start a discussion.

All that's in this PR is additional makefile targets for s390x and appropriate test/upload from GH actions.

Fixes: #811

[natalieparellano]

Thanks for the PR @agracey! I'm going to look into what it would take to get an s390x runner set up.

[agracey]

@natalieparellano There is a team at IBM that helps OSS projects build for s390x. I'm not associated with IBM but have talked with them about similar before. If you want, I can make a connection?

[natalieparellano]

@agracey that would be great! Thank you!

[jjbustamante]

Hi, @agracey anything I can help to move forward with this PR? Currently, the team is working on this PR which will modify the building workflow to include some steps to generate an SBOM, but I think the missing part here was to try to configure a runner with S390x. right?

[agracey]

But I think the missing part here was to try to configure a runner with S390x. right?

I think so. I had pushed for the opensource wing of IBM to host this runner but I've switched roles from the one where I was looking at this directly.

Let me ask if we may be able to donate some compute resources on our zSystem to host a builder. If we are able to do that, would that be acceptable? I think there's a way that we can have the build be done in the openSUSE network so it's more vender neutral.

[natalieparellano]

@agracey if you were able to produce a runner that would be awesome!

[dilipgb]

@natalieparellano I'm from IBM working on enabling knative on IBM Z system. As part of enablement one of the component in knative uses packeto-buildpacks to build images. I'm trying to get support for buildpacks for Z and looking what it needs to enable buildpacks on Z. I can build the binaries locally on my Z system but I'm trying to understand what is needed from buildpacks for enablement. As far as I understand from above conversation we need github runner agent for build. Is my understanding correct? Do let me know if anything I'm missing. Thank you!!

[natalieparellano]

@dilipgb I believe that's the case - we could always pull in the changes to the Makefile to enable building these binaries locally, but to test them in CI we need a runner.

[dilipgb]

@natalieparellano thank you. We really can not bring in s390x runner on github runner.

s390x is not supported as hosted or self-hosted runner in github actions as of today. There is some work going on to support it. PR which is WIP: actions/runner#2264

Given the current scenario, we can approach the problem in couple of ways:

1. We can run quick emulator on x86 itself to emulate s390x architecture and build the artifacts.
2. Other option is to run x86 based runner like an agent to connect to z virtual server instance in IBM Cloud and build artifacts on that vsi.

Please let me know your thoughts or you have any better approach which we can discuss.

[natalieparellano]

@dilipgb could we not build the binaries with GOARCH:=s390x on the amd64 runner? Using emulation seems fine to run the tests (or whichever ones are possible to run in this mode, such as unit tests). It might be possible for us to output the binaries with the caveat that they haven't been fully tested. As it is, we currently only run a subset of our tests against Windows and arm64.

[dilipgb]

@natalieparellano I tired with emulator (qemu) but the testing is extremely slow and job failing at linting with time out error.

https://github.com/buildpacks/lifecycle/actions/runs/5464862760/jobs/9947478745

But I can build the binaries from local x86 machine setting GOARCH:s390x which successfully runs on IBM Z.

We are thinking to use zvsi hosted on IBM Cloud to run tests and ssh via the action appleboy/ssh-action@v0.1.10 which allows us to ssh via github actions. If you are fine with the above recommendation I will proceed with hosting machine on our IBM Cloud account.

[natalieparellano]

Closing in favor of #1142