Add deploy to GHCR action

[maggie44]

Adds a deploy to GHCR action to build and deploy the Docker images

[maggie44]

Nudge

[andrewn]

@Maggie0002 Thanks for the nudge, just merged!

This looks like a good approach, let's hope it all builds ok!

[andrewn]

docker/metadata-action@v4 warns:

Warning: ghcr is not a valid semver. More info: https://semver.org/
32 Warning: No Docker image version has been generated. Check tags input.

So I'm switching to trigger on vx tags which works

[andrewn]

@Maggie0002 Now there's this error:

Error: buildx failed with: ERROR: failed to solve: failed to parse stage name "balenalib/%%BALENA_ARCH%%-alpine:3.14-run": invalid reference format: repository name must be lowercase

It kind of makes sense, I need to figure out how to set %%BALENA_ARCH%% somehow. I'll do some searching, but any ideas?

[andrewn]

Ok, I ended up using matrix strategy to map BALENA_ARCH for each platform.

Then there was a problem with cargo build which is also fixed.

🎉 Packages are available!

I'm travelling so won't be able to test on a real pi until the end of February.

[maggie44]

Amazing thanks! Some great fixes in here I wouldn't have thought of.

Does this unpack all of the different architectures to build? Or maybe it is overwriting with the final build?

${{ matrix.platforms }}

I was expecting there would be a arch tab like there is here: https://github.com/balena-labs-research/starter-interface/pkgs/container/bsi

And when running on a NUC I get the error:

WARNING: The requested image's platform (linux/arm/v6) does not match the detected host platform (linux/amd64) and no specific platform was requested
standard_init_linux.go:219: exec user process caused: exec format error

I wonder if it is only running for linux/arm/v6 which is the first platform listed.

I also wonder whether we need to use the balenaLib images at all. We could try with just alpine:3.14 and then wouldn't need to pass in the different architectures. Of course your solution would be better to avoid changing things we don't need to, but if the standard Alpine containers work, it would be a way to simply the build.

No rush though, enjoy your holiday :)

[andrewn]

I think I see the problem, the matrix strategy re-runs the job with each set of architectures so I guess the job that finishes last is the one that gets the tag in GHCR.

I'll try with just alpine:3.14 and see if that builds ok and then we can remove the matrix. Otherwise, I'm not really sure how to workaround it.

[andrewn]

@Maggie0002 What an ordeal.

I've tried with the non-balena alpine images and couldn't get them to build. I was getting this kind of error

#15 313.2   no REF_DELTA found, cannot inject object; class=Indexer (15)

Run #18

I've tried to revert to the matrix strategy build which worked before (#7) and now pretty consistently getting rust errors related to running out of memory (e.g. #27).

I'm not sure what to try next?

[maggie44]

What's this fix do?

      # Workaround cargo error failing build
      # https://github.com/marketplace/actions/docker-on-tmpfs
      # Error: https://github.com/andrewn/librespot-docker/actions/runs/4121241814/jobs/7116738264#step:8:567
      - name: Run Docker on tmpfs
        uses: JonasAlfredsson/docker-on-tmpfs@v1
        with:
          tmpfs_size: 5
          swap_size: 4
          swap_location: "/mnt/swapfile"

tmpfs may be written to RAM, which means if it is being stored in that directory then that directory is content is written to RAM, which may mean running out of memory?

[maggie44]

May also want to try disabling the cache:

importing cache manifest from gha:2682110710969971717

          cache-from: type=gha
          cache-to: type=gha,mode=max

Could be an overlap of caches between the different builds.

[andrewn]

What's this fix do?

      # Workaround cargo error failing build
      # https://github.com/marketplace/actions/docker-on-tmpfs
      # Error: https://github.com/andrewn/librespot-docker/actions/runs/4121241814/jobs/7116738264#step:8:567
      - name: Run Docker on tmpfs
        uses: JonasAlfredsson/docker-on-tmpfs@v1

This action works around an armv7 build issue that I was getting before. From the docs:

This action was created to solve a JonasAlfredsson/docker-nginx-certbot#30 that occurs when building the latest pip cryptography package inside a QEMU emulated linux/arm/v7 environment (e.g. Rasberry Pi) on a linux/amd64 computer.

It moves the whole docker build onto tmpfs so yeah, disk space is limited. But without it the build also fails.

[maggie44]

Wow, these quick fixes are never quick huh. Really appreciate the help with this.

Have you tried it again today? Worth doing a re-run just to check whether it was actually network issues like some of the errors suggest, perhaps the GitHub workflows were just having a bit of a moment.

Or: PyO3/maturin#294 (comment)

[andrewn]

I've been running a slightly different action workflow today, just the arm64 and amd64 without tmpfs.

It successfully builds these two containers, but they're still not linked.

My plan is to:

1. Get these two platform images to be linked under the 0.4.2 tag using this docker-manifest-action
2. Get the arm/v7 platform built and linked, probably using the tmpfs approach
3. Get arm/v6 built and linked

Have you tried it again today? Worth doing a re-run just to check whether it was actually network issues like some of the errors suggest, perhaps the GitHub workflows were just having a bit of a moment.

I can but I think avoiding the tmpfs step is a good idea.

[andrewn]

1. Get these two platform images to be linked under the 0.4.2 tag using this docker-manifest-action

arm64 and amd64 are building, and linked together on the containers page.

I switched to use the cargo's "sparse registry" which seems to keep memory under control. But I guess it'll take a few more runs to see if the builds are stable.

I'll move onto getting arm/v7 and arm/v6 building next 🤞

[andrewn]

I don't think rustup supports installing on arm6 for compilation. I found some docs about that target being Tier 2 without host tools which means it doesn't include cargo:

#12 2.643 rustup: installer for platform 'armv7-unknown-linux-musleabihf' not found, this may be unsupported

The sparse registry feature will be in Rust 1.68 which will be released next week, March 09 2023. So I'm going to pause this until it's released and makes it's way into Alpine edge.

I'll try and build the amd64 image locally and push to Docker which will at least unblock balena-io-experimental/balena-sound#623

[maggie44]

Hey @andrewn,

I'm afraid I am no longer working at Balena. It looks like you're making good progress, but I would suggest posting on the forums of balenaSound repo where someone may pick it up.

[andrewn]

@Maggie0002 Thanks for letting me know.

All the best with whatever you're doing next and thanks for your help with this!

[andrewn]

Taking a step back, the reason we need to do this compilation at all is because the Alpine package of librespot compiles the ALSA backend and not the PulseAudio one. So I've opened a PR for Alpine to include both, which will remove the need to compile at all.