flatpak / flatpak-github-actions

Build your Flatpak application using Github Actions
https://github.com/marketplace/actions/flatpak-builder
MIT License
162 stars 42 forks source link

Restoring cache of the wrong `arch` #167

Closed vixalien closed 9 months ago

vixalien commented 11 months ago

Hello. I have a [workflow that builds a nightly flatpak for my app] on every commit.

The workflow has two architectures: x86 and arm. Because the ARM build is emulated, its builds always finish last.

This means that my x86 builds always try to restore the cache from the ARM build (because it always finishes last), which does not work. Here is an action you can check to see the behaviour: https://github.com/vixalien/muzika/actions/runs/7039137348/job/19157539977

I attached the logs:

Run flatpak/flatpak-github-actions/flatpak-builder@v6
  with:
    bundle: com.vixalien.muzika.nightly.flatpak
    repository-name: gnome-nightly
    repository-url: https://nightly.gnome.org/gnome-nightly.flatpakrepo
    manifest-path: build-aux/flatpak/com.vixalien.muzika.Devel.json
    cache-key: flatpak-builder-032b880e6a5da2f4ddd501c95ca21e7b67cfa6d0-nightly
    arch: x86_64
    build-bundle: true
    run-tests: false
    cache: true
    restore-cache: true
    branch: master
    verbose: false
/usr/bin/docker exec  744742b8f89f6cfb80b41c294758f7342026a0d2ab0d8157fb9fac595f12ff11 sh -c "cat /etc/*release | grep ^ID"
/usr/bin/flatpak remote-add --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepo
Received 130023424 of 258351338 (50.3%), 124.0 MBs/sec
Cache Size: ~246 MB (258351338 B)
/usr/bin/tar -xf /__w/_temp/3f12f78c-a217-47e3-86b8-5cfbb035cc09/cache.tzst -P -C /__w/muzika/muzika --use-compress-program unzstd
Received 258351338 of 258351338 (100.0%), 123.1 MBs/sec
Cache restored successfully
Restored cache with key: flatpak-builder-18deaf17f52a7ff697fc9539917e90cb9d253847-nightly-aarch64
__________________________________________________________________________________________^

Building the flatpak..

Notice that the restored cache has a -aarch64 suffix, even though we are making an x86 build.

It seems that currently, the logic of the action is to restore the latest cache, and does not check that the requested cache was made for certain architecture or not.

vixalien commented 9 months ago

It seems to be fixed, or was never an issue. Sorry.