chore: add CI to publish Flatpak to Mixxx repo

[acolombier]

This is a follow up to @djantti 's work.

As discussed before, we could consider dropping the PR command, since one could download the Flatpak build asset manually and install it, like for the other targets Removed now to allow quick merge ahead of 2.5 final release

[acolombier]

Hi @djantti, would you be happy to help reviewing this PR?
We are about to get 2.5.5 out and it would be very to offer a way for Flatpak user to be able and install it.

[daschuer]

I have found here a similar solution:
https://github.com/futrnostr/futr
(just for reference)

[daschuer]

How can we test this?

[daschuer]

Pinning the host keys is not a bad idea security wise. Can we move them to a GitHub secret to be able to update them easily? There are also other part of the workflow that can use the pinned version.

Contacting the wrong server is probably not a security thread. So we may also consider here the old method and update all workflows in a separate PR.

[acolombier]

Can we move them to a GitHub secret to be able to update them easily?

Generally, I would recommend to non-sensitive information visible and transparent. I could move it to a repo variable though.

So we may also consider here the old method and update all workflows in a separate PR.

Fair. I would argue that in the case of shared runner, DNS cache poisoning is something we should protect ourself against, but agreed it can be approved in future PRs and doesn't need to delay the release any further.

[djantti]

Ooo, really nice! It's a bit complicated, but less so than I feared it would be without flat-manager. 😅

I'd prolly change all references of channel to branch, since that's what they're called in Flatpak documentation. But it's just a naming thing and doesn't really matter.

[djantti]

We could add the repo public GPG key at the end here with GPGKey=<key>, base64-encoded and everything in a single line.

[acolombier]

Ah good should. Do you know if there is an easy way to extra the public key from the signed flatpak that are already pushed?

[djantti]

Hmm, looks like there are binary .sig files inside a Flatpak repo, but I couldn't find a match to my testing public key. But I guess the public key should be the same as the Ubuntu PPA public key?

There's also a DefaultBranch=<branch> option we could add (and prolly set to stable), but I haven't tested that. I think it should allow installing without specifying a branch. And we're not using the default master branch, so that actually might be important. 🤔

[daschuer]

@rryan 's key can be found on the Ubuntu keyserver:
https://keyserver.ubuntu.com/pks/lookup?search=6F709194D92C4947&fingerprint=on&op=index

[acolombier]

Done

[acolombier]

How can we test this?

This was previously tested as PR command, using the same action via workflow_call (see this run). There is a chance that something foes wrong with tagging but I would suggest we fix forward since we need the download server private key and thus will be tricky to test fully on our forks.

I'd prolly change all references of channel to branch, since that's what they're called in Flatpak documentation

Sounds like a great call. Could you share your recommendation?

[djantti]

I'd prolly change all references of channel to branch, since that's what they're called in Flatpak documentation

Sounds like a great call. Could you share your recommendation?

I was just thinking of a quick sed -i -e 's/channel/branch/g' -e 's/CHANNEL/BRANCH/g' flatpak.yml to change the naming. Nothing more fancy than that. ☺️

[acolombier]

Apologies for the mess - I though I was amending my test commit but realised to I was messing up with the fixup too late.

I have run further tests, added all signing and confirm it was working. Added some edge case (snapshot) and fixed a bug with metadata.

Run ID for evidence: https://github.com/mixxxdj/mixxx/actions/runs/22932552442/job/66557059929

Testing:

flatpak --user remote-add mixxx https://downloads.mixxx.org/flatpak/repo.flatpakrepo
flatpak --user install mixxx org.mixxx.Mixxx
# or flatpak --user install app/org.mixxx.Mixxx/x86_64/snapshot as I have put a snapshot build in there

[daschuer]

I can confirm it works, however we need to have a look to the branch naming.
We have currently

• https://downloads.mixxx.org/snapshots/
• https://downloads.mixxx.org/releases/

And on our PPA:
Mixxx Releases
Mixxx Beta Releases
Patch Builds
Nightly Builds

We probably want to have similar four streams like in our PPA?

snapshot alone does not work well, because we have two snapshot streams. We have the same issue for nightlies by the way, legacy we cant easily change. On our websites "Development Snapshots" points to the current alpha aka nighlies. Here Snapshot is something else.

Here we have now

• stable
• beta
• alpha
• snapshot

Which implements a different strategy.

Can we remove the snapshot feature here, that links to any branch? This has been only added for testing, right?
Than implement branches similar to our PPA?

[djantti]

Working great here too! 🚀

Commit signing works, the repo log looks good and installing works even without specifying the branch. There's only one branch on the repo, so it prolly selects that automatically.

[acolombier]

Happy to remove snapshot.

When it comes to nightlies, this won't really suit Flatpak, as we will get continuous integration into it, unlike the PPA, that makes nightly builds and thus doesn't build every single merges.

Are you happy with keeping stable, alpha and beta? This would well align with our development strategy and since this Flatpak repo is a development repo, that should make things clearer.

[daschuer]

Our PPA also builds every single merge. At least it should. The "nightly" label is used because it is a widely established term for the bleeding edge build form the main branch in the flatpak ecosystem:
See this for reference:
https://develop.kde.org/docs/packaging/flatpak/publishing/

For my feeling "nightly" seems to be still a very common term more common than "alpha".
"alpha" works for me as well though.

I think stable is the mostly uses term for the Tagged release version with Flatpak.

So we need a name for the mixxxpatches
stable-patches or just patches or ...

[djantti]

I've always thought nightlies as scheduled daily builds from the main dev branch. But I guess it could also be from another branch, like a nightly beta. And Gimp for example has nightly Flatpaks, but they're actually weeklies built using a Gitlab cron job. 😁

If I'm understanding correctly, our Flatpak repo would mainly be like a continuously rolling development repo for stable, beta and alpha branch builds. It's a really cool approach, especially for testing purposes.

From that perspective the branch names do make sense to me. But things might indeed get confusing if the repo will also have tagged stable / beta release branches.

[daschuer]

@djantti, my idea is to offer the same updates our PPAs do. The issue here is that a new user sees the branch options with the branch-ls option and shall instantly know from its learned knowledge what he can expect by following one or another branch. Copying the branch names from the PPA would be one option. But for my understanding they are foreign in the Flatpak world.

What are the best names for our four branches (streams). Can you draft a proposal?

[acolombier]

If I'm understanding correctly, our Flatpak repo would mainly be like a continuously rolling development repo for stable, beta and alpha branch builds. It's a really cool approach, especially for testing purposes.

Yes, this was the idea!

I've always thought nightlies as scheduled daily builds from the main dev branch.

So do I, thus my confusion!

I think stable is the mostly uses term for the Tagged release version with Flatpak.

Not sure I understand. My thought was to have stable for stable release, such as 2.5.4, or soon 2.5.5 and 2.6.0, so this would include patched version, once they get released.

beta would include all beta branch, for every push to 2.6 at present.

And alpha is for every push to main, but happy to use nightly if we feel like this is a clearer terminology.

Only one not included would be push to stable branch (e.g 2.5) but since we don't have testing here, this sounds out of scope. This was my thought for allowing snapshot, but a user can also still download the .flatpak file from a 2.5 build, like they would do for other platform already.

So are we happy to move forward with 3 branches - stable / beta / nightly. Does that sounds a good first approach? We can always rename beta and nightly later, stable would be a bit of problem tho long term, we don't want stable builds in there and use Flathub instead for that.

[daschuer]

Not sure I understand. My thought was to have stable for stable release, such as 2.5.4, or soon 2.5.5 and 2.6.0, so this would include patched version, once they get released.

Yes, this is the equivalent for Mixxx Releases

beta would include all beta branch, for every push to 2.6 at present.

Yes, this is the equivalent for Mixxx Beta Releases

And alpha is for every push to main, but happy to use nightly if we feel like this is a clearer terminology.

Yes, this is the equivalent for Nightly Builds
Both options work for me.

Only one not included would be push to stable branch (e.g 2.5) but since we don't have testing here, this sounds out of scope.

Ah yes you are right, we have introduced it on our PPA, because we don't have Github builds for every 3.5 commit for every Ubuntu version. In case of Flatpak testers can pick the Workflow artifact.

So are we happy to move forward with 3 branches - stable / beta / nightly. Does that sounds a good first approach? We can always rename beta and nightly later, stable would be a bit of problem tho long term, we don't want stable builds in there and use Flathub instead for that.

Interesting thought. We don't have a stable build anyway right now. So do we probably don't want to introduce it at all and go with two branches only?

[acolombier]

Both options work for me.

Same - Leaving the choice to @djantti :D

In case of Flatpak testers can pick the Workflow artifact.

Sounds good. I tried and you just have to download it and flatpak install so this feels "user friendly" enough if we ever need somebody to test a patch candidate (or PR build).

We don't have a stable build anyway right now. So do we probably don't want to introduce it at all and go with two branches only?

The reason for introducing it is to offer a workaround to the abandoned Flathub distribution, which is stuck to 2.5.2. This would have offered a way to our Flathub user to install the latest versions (2.5.5, but also 2.6.0 coming soon with STEM)

I know a few persons that have been desperate for a solution, and looking at the listing, we have 180k installs so this isn't an isolated platform.
We may also decide to keep stable on the long run as a mirror to Flathub as well, but what I meant is that this doesn't aim to become the primary channel for Flatpak install.

[djantti]

Nooo, I was going to suggest stable, prettystable and omgdefinitelynotstable. 😆

Flatpak users are indeed most familiar with stable, beta and nightly repositories / branches. Unstable is also quite common for the latter. Alpha is a traditional choice, but perhaps more rare in Flatpak world.

Personally I've always thought nightlies as scheduled builds. But if Gimp can have weekly nightlies, then we can definitely have an awesome rolling nightly branch. And hey, it's always night somewhere.

So stable, beta and nightly sounds good. They're commonly used, very distinct and easy to remember.

[daschuer]

OK, what situation we may face with this mirroring issue?

Such a repository is for automatically distributing updates. Will users than have the Flathub version and our version side by side? Will they face conflicts or will Flatpak be smart enough to use the most recent version form either source?

[acolombier]

Flatpak would prompt which which remote you want to install from.

Updates seem to only pick from the already installed remote. But user can run the following: flatpak --user install --or-update org.mixxx.Mixxx. In this case it will offer them to re-install from mixxx repo (if they added it).

They can also have both version side-by-side. Package seems to be both identified by their ID, remote and branch, meaning that user can also technically have stable and beta install and those wouldn't conflict.

Regarding the most recent version, as far as I understand, versions are assume based of the ostree commit age. It doesn't look like there is any attempt to compare the actual version together.

I would suggest we get the repo out without to much announcement at first so we can confirm all these assumptions as we are getting better with managing it. For 2.6 (hopefully going out in a matter of weeks now), we can share the news (via a post+download page update), as we would have confirmed everything works.
What do you think?

[acolombier]

Updated the branch to stable/beta/nightly and removed the snapshot usecase!

[djantti]

Package seems to be both identified by their ID, remote and branch, meaning that user can also technically have stable and beta install and those wouldn't conflict.

Yeah, this is why I'm glad we're going with the branches approach.

You can have all three branch versions installed at the same time and run them with something like flatpak run --branch=beta org.mixxx.Mixxx. And to change the default, just run flatpak make-current org.mixxx.Mixxx beta. The desktop launcher shortcut will be automatically updated to reflect the change.

And since we use the default master branch for PR bundle builds, you can have one of those installed at the same time too. This is super flexible for both users and developers.

[daschuer]

This is just the latest release version. Can we remove or set the version number automatically?

[daschuer]

Ah, scratch that. We need to edit the branches anyway..

[acolombier]

Yeah, I think we can improve this so the version gets inferred in the future. Not quite sure how yet tho, so let's keep that as a later improvement

[daschuer]

Ready for merge after rebase. Thank you for this nice effort.

[acolombier]

Rebased and ready to go!

[djantti]

Thank you! This is going to be a really awesome feature! 🚀