I'm trying to build an extension for an app in my personal repository. For that the app needs to be installed from that repository. However I also need the rust extension for the freedesktop sdk from flathub. As only one repository to install dependencies from can be specified, there is always one missing.

My idea to solve this would be to allow running a custom script before the build, in which I could install the required app from my repository.

I am probably missing something important but I can't seem to test dbus services and/or clients:

GLib.Error g-spawn-exit-error-quark: Error spawning command line “dbus-launch --autolaunch=180049aac266486c89ec8c79e659685e --binary-syntax --close-stderr”: Child process exited with code 1 thrown in resource:///org/gnome/gjs/modules/core/overrides/Gio.js (line 457)
    get session@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:457:24

It seems that is not possible to spawn/launch services from within flatpak-builder. I tried to reproduce the dbus-launch command and got this:

[📦 org.gnome.Sdk project]# dbus-launch --autolaunch=180049aac266486c89ec8c79e659685e --
Autolaunch requested, but X11 support not compiled in.
Cannot continue.

I also tried adding more permissions to test-args (e.g. --socket=session-bus, --filesystem=host, etc) , but didn't make any difference.

Any ideas?

The example in the readme uses the version 4 of this action but the latest release is 3, maybe you forgot to tag a new release? (Asking because I need the gnome nightly image in my project's CI :P)

The typical convention for GitHub actions is for the v6 tag to point to the latest v6.x.x version. Currently, v6 points to the release from a couple of weeks ago with the issue overwriting the Flatpak branch.

This means that automated PRs to bump dependencies in workflow files, like dependabot are proposing bumping to the broken v6 tag, as they typically only bump major versions. See this PR against an elementary repo: https://github.com/elementary/appcenter-reviews/pull/448/files

See the GitHub Actions docs for further info on the conventions: https://github.com/elementary/appcenter-reviews/pull/448/files

If I understand the documentation correctly, it would be possible to do something like flatpak build-bundle, but for debug symbols instead?

If a build is able to successfully load a cache, then it will produce an error trying to save a cache with that same key. See the "Annotations" section in https://github.com/rkoesters/xkcd-gtk/actions/runs/1352160876 as an example.

The error is ReserveCacheError and it would be better to log an info message that says the cache already exists instead of an error message. Otherwise, anytime the cache is successfully used, errors are reported.

Is it possible to add an option for arch so that we can cross-compile for eg. aarch64? It would be convenient to have builds churned out for x86_64 and aarch64 for testing on mobile devices.

I've been going through the code of the action, and found that it assumes the app module is the last one in the manifest. While this is most of the time because Builder handles it that way, it doesn't mean it's always the right thing to do

The action should perhaps use the last module by default, but at the same time allow setting another module from its name

While trying to switch to default cache-key in obsproject/obs-studio#5137.
We were trying remove the cache-key settings when this issue happen.

An unexpected issue has occurred:

Cache Size: ~1123 MB (1177260662 B)
/usr/bin/tar --use-compress-program zstd -d -xf /__w/_temp/a957e912-7502-4f61-a192-d3e489b47e8d/cache.tzst -P -C /__w/obs-studio/obs-studio
Cache restored successfully
Restored cache with key: -x86_64

https://github.com/bilelmoussaoui/flatpak-github-actions/blob/9b33ba80aec2fc2652e05f15f19929fa98182889/flatpak-builder/index.js#L209-L212

It seems that cacheKey even if empty does not fullfill the condition and generate a wrong cache key which ends up being -x86_64 in our situation.

Set The bundle name only one, how to export other software in the repo folder, for example, there are 3 apps all need to export, log:

Committing stage finish to cache
Exporting org.winehq.WineWechat to repo
Commit: ebbaeb6dc33e8240382dc1f87d6dce7120c1cacedbfee1c1152c11bf8a898855
Metadata Total: 257
Metadata Written: 110
Content Total: 2498
Content Written: 2343
Content Bytes Written: 625556372 (625.6?MB)
Exporting org.winehq.WineWechat.Debug to repo
Commit: 78cf340d32199d873d6ea775772f0608b6e95fc90e06ff8fe3a0c5fd883da9c5
Metadata Total: 1731
Metadata Written: 481
Content Total: 10071
Content Written: 5396
Content Bytes Written: 152863433 (152.9?MB)
Exporting org.winehq.Wine.gecko to repo
Commit: c9910ea60a358f611eea273baa8b6d279cef3f94edf285f66d03a9c9751674c0
Metadata Total: 13
Metadata Written: 7
Content Total: 5
Content Written: 5
Content Bytes Written: 110310741 (110.3?MB)
Exporting org.winehq.Wine.mono to repo
Commit: 765cedd187ad66cf61a009e254e454f135fbf12d20dd225daf3983828ef364c4
Metadata Total: 989
Metadata Written: 468
Content Total: 2953
Content Written: 1648
Content Bytes Written: 198127187 



# only one

/usr/bin/flatpak build-bundle repo org.winehq.WineWechat.flatpak --runtime-repo=https://flathub.org/repo/flathub.flatpakrepo --arch=x86_64 org.winehq.WineWechat master

I noticed while working on #83 that (in the case of git, for example) flatpak-builder will build from the sources defined in the flatpak manifest. This isn't surprising, but it's almost certainly not what you want if your manifest points to your main branch and you are running tests on pull request.

I plan on taking a crack at this eventually, but if someone else wants to take it on before I do, feel free.

While that feature is quite nice, actually i want to tag the flatpak file itself with the architecture. When i do this, the automatic tagging results in a double tag on the artifact name. So it would be nice if that could be disabled, or if it could be configured to tag the flatpak file itself so that both names carry that architecture postfix.

When using this github action with an extension (which, as far as I know, creates runtime/RDDN/arch/version instead of app/RDDN/arch/version), the action fails. According to my logs, it fails because it cannot find app/RDDN/arch/version. Unfortunately, I can't seem to find an option to have it search for runtime instead of app.

I would like to see some sort of option to allow it to support runtime/extensions

It might be me, but I think the explanation for run-tests isn't very helpful.

Currently, we use master as the default branch which doesn't work if the manifest has a branch specified on it. We should expose an input to set one and default to the one in the manifest. If none of both is set we fallback to master.

flatpak-builder's flag --install-deps-from can be called multiple times to specify multiple repositories.

The action doesn't do anything complicated. We should provide a base aarch64 image that already contains whatever is needed for emulation through qemu to work.

I'm new to building Flatpak apps and I wanted to use this action. For me, it was problematic to figure out what does "flat-manager token" means and where to get it. The main source of confusion was the official Flathub tutorial, because it suggests publishing manifests on GitHub and using their CI tools instead of directly publishing built app. After that, when I opened flat-manager repo I assumed that I was looking in the wrong place, because it made me think that it only hosted a server side app. I think mentioning in docs where to get flat-manager-client and how to generate token with it would make things much easier.

For now we only have fdo//20.08 pre-installed. We should provide an image per runtime per version, I think we can hack some CI to automate all of that using Github Actions and publish the images somewhere like Dockerhub

Since the addition of arch option, the used cache key isn't the same. Restore (prepareBuild) use only cacheKey and don't use arch but return ${cacheKey}-${arch}, which make the action use two different key.

And you should maybe add a warning explaining that adding ${{ matrix.arch }} to the cache-key parameter is not necessary or even recommended.

diff --git a/flatpak-builder/index.js b/flatpak-builder/index.js
index d9ae689..2f978ef 100644
--- a/flatpak-builder/index.js
+++ b/flatpak-builder/index.js
@@ -196,7 +196,7 @@ const prepareBuild = async (repositoryName, repositoryUrl, manifestPath, cacheBu
 
     const cacheHitKey = await cache.restoreCache(
       CACHE_PATH,
-      cacheKey,
+      `${cacheKey}-${arch}`,
       [
         'flatpak-builder-',
         'flatpak-'

PS: I could make a PR, but I don't know how to generate the dist/index.js

I build a bundle for the x86_64 architecture here. After installing the bundle locally, I get the aforementioned error when trying to run it (with flatpak run --command=sh <ID>, then calling the binary from /app/bin; plain flatpak run outputs nothing).

Is there a way to don't use static deltas inside workflow .yml to avoid aarch64 "exceeded maximum size" errors?

Thanks

While 8326776 updated flatpak-builder's dependencies (for example, updating @actions/core from 1.2.6 to 1.10.0), it seems that the dependencies of flat-manager were not updated. I asked @GeorgesStavracas about this and he suggested that this might have been an oversight and asked me to open a GitHub Issue for follow-up and tracking.

Add a test case using this manifest https://github.com/grulja/MediaWriter/blob/ad6cf9fdf479bfc289e808c5c3b5283587e8f4e3/dist/flatpak/org.fedoraproject.MediaWriter.json

It would be useful if this action could also create and upload flatpak .Locale runtime automatically, so translators won't have to build the app themselves to see and test their own translation.

Hello!

When using flatpak/flatpak-builder I find it useful to provide verbose output using the --verbose flag.

What do this project think about allowing to specify this also through this GitHub action?

        with:
          verbose: true

If this is per default set to false, I argue this would be a fully backwards compatible addition.

Adding support for it should not be too complicated: I suspect we need one more if check with an args.push in flatpak-builder:index.js for the build function, and then just update the arguments and documentation.

By default, the flatpak branch name is "master", it would probably be a good thing to default to something else like "main" for v4

See Matching a cache key and actions/toolkit/cache#restore-cache.

Since the big migration happened, seems like the Flatpak action is broken. See for example https://github.com/obsproject/obs-studio/actions/runs/3064364729/jobs/4947401540

GitHub Marketplace seems not to list the v4 version of the action (see here and here).

Stuff like setting the proper branch, the correct remote version and all :)

It seems the fix for CVE-2022-39253 broke cloning of submodules for flatpak-builder: https://github.com/jacktrip/jacktrip/actions/runs/3427723069/jobs/5711073035

Right now flatpak is hard coded in the build command https://github.com/bilelmoussaoui/flatpak-github-actions/blob/master/index.js#L137. It would be nice if we could customize that.

In https://github.com/flatpak/flatpak-github-actions/blob/master/flatpak-builder/index.js#L59, there's this:

    this.branch = 'master'

which sadly overrides the branch name from https://github.com/flatpak/flatpak-github-actions/blob/master/flatpak-builder/index.js#L29

Sadly this caused OBS to publish a beta release in the master branch of Flathub Beta, instead of beta.

Currently, the wip branch uses nahuelwexd/flatpak-docker:latest we should switch to using a docker image based on Dockerfile hosted here on github

cc @nahuelwexd

When using this action similarly to the suggested layout with both x86_64 and aarch64, the aarch64 build fails on setting up Gnome Sdk:

Installing runtime/org.gnome.Sdk/aarch64/43
Error: Failed to install org.gnome.Sdk: While pulling runtime/org.gnome.Sdk/aarch64/43 from remote flathub: URI https://dl.flathub.org/repo/deltas/iY/cHs6KvGy7K1Q8xOxbwGJF3V4+aKBr6e+ChYjrRGEc/17 exceeded maximum size of 8193001 bytes
Error installing deps: running `flatpak --system install -y --noninteractive flathub org.gnome.Sdk/aarch64/43`: Child process exited with code 1

Flathubs buildbot and the x86_64 architecture work fine.

Recently I've been looking into publishing OBS Studio into Flathub directly, and I noticed that the Flatpak builds were generating version numbers with the -modified suffix. OBS generates these version numbers by running git describe --dirty="-modified".

Turns out, this action modifies the original Flatpak manifest file regardless of any actual changes. I think it's probably better to save the modified Flatpak manifest in a separate file, and build from that, instead of modifying the original directly.

I use flatpak-github-actions in my project. My workflow file: https://github.com/FWGS/xash3d-fwgs/blob/master/.github/workflows/c-cpp.yml#L67-L91

The log file shows few lines before complete fail:

(flatpak-builder:683): GLib-CRITICAL **: 09:27:17.094: g_propagate_error: assertion 'src != NULL' failed
Error: module bundle-setup: Protocol "data" not supported or disabled in libcurl
Error: Build failed: Error: The process '/usr/bin/xvfb-run' failed with exit code 1

The action log file is https://github.com/FWGS/xash3d-fwgs/actions/runs/4971642736/jobs/8896307408

I noticed this yesterday, but this probably has been broken for a week now. I also tried to upgrade from v5 to v6.1, and it didn't help.

If there are any steps should be done to debug it, I would gladly help.

When using this Action CMake's FetchContent fails with the following message:

fatal: unable to access 'https://github.com/TartanLlama/expected/': Could not resolve host: github.com

Hello,
is it possible to add support for Electron2.BaseApp?
Or if it's now supported, how to build it with your action?

Thank you.

we will need to provide a way to set a remote url & a token and use flat-manager to upload the build to the remote.

Seems like Flathub requires quite a few undocumented extra validation steps:

• Run appstream-util validate from a relatively new appstream-glib (or via Flatpak from Flathub)
• The app-info directory in the build dir needs both app-info XML and 128x128 icons
• Screenshots need to be mirrored to https://dl.flathub.org/repo/screenshots (#63)
• Screenshots need to be committed to screenshots/$architecture (e.g. $ ostree commit --repo=repo --canonical-permissions --branch=screenshots/x86_64 builddir/screenshots)

I'm leaning towards either adding a flathub-validations boolean option to the flat-manager action, or adding a validations string array option. Not sure which one is better.

Flatpak Builder have a branch called run-without-fuse, that is actually being used in GNOME to build the GNOME Runtime Images, used for CI in the GNOME GitLab instance. Actually, we've so much problems trying to use the flatpak-builder build from Fedora, so I think we should use that branch instead.

I've no idea how it works, but it would be great.

I've tried to use your action. It looks very convenient but I fail to see how to get the output. Is there something I'm missing?

https://github.com/aleixpol/maliit-flatpak/actions/runs/188988338
https://github.com/aleixpol/maliit-flatpak/runs/929006125?check_suite_focus=true

https://github.com/aleixpol/maliit-flatpak/blob/master/.github/workflows/flatpak.yml

Thanks in advance!

During my work on using Flatpak Builder in my project (see CodedOre/NewCaw#46), I ran into the problem that the appdata test fails as appstream_util fails to assert Gio. ProxyResolver:

(appstream-util:12): GLib-GIO-CRITICAL **: 10:28:50.002: g_proxy_resolver_lookup: assertion 'G_IS_PROXY_RESOLVER (resolver)' failed

I have also seen that the CI builds of Dialect also fail due to the exact same issue, so I assume the issue is with the Flatpak Builder action.

Used image: gnome-nightly

Link to the failed build
The workflow file

We're packaging a java application. To do so, we first build it with maven and then use the generated .jar files to build the flatpak. The manifest is located in a subdirectory and must be executed from there to find the maven output. Is this possible?