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.
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:
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.