We would like to build and test our application using flatpak. So the idea is that a build machine would build the .flatpak self countained file that another machine could then use to run automated tests on our application. Once we are happy the tests are good then we would like to upload this prebuilt and tested flatpak file to flathub for publication.
However, it seems the flatpak publishing can only be done by building again on the flathub servers (which may result in something slightly different to what we tested). We also don’t need to build again as we already did that as part of our own local build process.
So ideally, we would just upload the flatpak file to flathub when we want to publish our update.
So, this is certainly something that we’re thinking about. And in Seeking contractors for work on Flathub project we’re looking at ways to manage binary uploads from verified developers and have just appointed some contractors to begin working on this, along with a number of other improvements to the developer experience.
I am interested in the question about if the build could result in something different from what you tested, if your manifest it written to the flathub standards it really shouldn’t, although we can’t guarantee fully reproducible builds currently this is certainly something that flatpak is intended to make a lot easier so I’d be really interested in your specific concerns or if there’s anything else you have to share. I love your concern though, this is exactly the kind of problem we believe real developers have and want to help solve!
Thank you for you response. The reason I think there is a potential for something different to be built on the flathub servers vs what we used internally is bugs in flatpak or different versions of flatpak-builder used on our side vs what was used on the server side. Maybe that is being a bit paranoid but if we could guarantee the binary that we tested was identical and that was what we published that would remove this possibility.
At the moment I’m actually dealing with what appears to be a bug between how the flathub server builds vs how we build internally. When I build on the flathub server using the same manifest and sources it works but when building on my local machine it all builds and can install but when the app is run I get this error:
bwrap: Can’t mkdir /app/lib/i386-linux-gnu: Read-only file system
error: ldconfig failed, exit status 256
I will post a separate question about this but it kind of supports my concerns that what we build as a binary and run automated tests on can be different to what flathub has from the same sources.
Sure, and work is now very much ongoing on this topic btw.! Sorry that I’ve only just looked back now but doing something like
$ flatpak install org.gnome.Platform.Compat.i386
I think would help (or the 32 bit compat for whatever your platform is). You might also want to make sure that your app requires a 32 bit extension rather than marking it as just optional.
Just want a confirmation if this is now implemented a year later.
It is absolute mandatory for many companies to not transfer their source code to questionable out of house locations. And if the app contains encryption it might break laws too.
So flathub need to be a store and a build service as two indepedent services.
My understanding is, that they each have gotten a private key/secret to upload directly to flathub.
I’m not sure if this is still treated as some kind of alpha/beta, as allowing people to upload directly will certainly be something, where flathub needs to trust that party to some degree.
I would very much like to upload my electron application (https://super-productivity.com) as a single file as well. Does anyone know where I might best ask how to accomplish this?
What road would you suggest to go down when publishing an electron builder app?Publishing to flathub is a quite popular feature request. Several people tried to get it running, but so far everyone has failed.
Thank you very much! I checked Joplins approach, but it seems like incredibly tedious to setup. Is there any hope that this might get easier in the future?
Some like element/riot or slack (from the top of my head) repackage the .deb file - that sidesteps most things, but can also cause problems with other arches, if you don’t set those up correctly (or ignore building for them, which is possible, but not nice)
I would add this to thread my +1 for a more streamlined way to publish on Fluthub.
We currently distribute https://morgen.so via Snapstore and there it’s just snapcraft upload ./morgen.snap. Would love to see something as easy.
It sounds like the OP’s problem would be solved if Flathub’s builds were available as private/draft/prerelease downloads, so developers can test them before deciding whether to publish the build as a new release.
So rather than
Build locally (or on your own infrastructure).
Test locally.
Upload to Flathub.
You would instead:
Build on Flathub (but don’t publish the build).
Download the build (via secret develper link / API).
Test locally.
Publish the original Flathub build (so everyone can download it).
This solves the security issue since the build still takes place on Flathub.
Maybe this is already possible? I haven’t used Flathub so I wouldn’t know.
Yeah, that’s possible and in fact the common flow. There is even an artificial 4 hour delay between merge and final publishing, so that you can test the build and remove it in problematic cases.
