I’ve recently had 2 different users, in 2 different repositories propose to generate updated Node and Cargo sources automatically using GitHub actions:
What are the recommendations for those?
Is it alright to run those actions?
How often can we run them?
Are there templates that one can use to generate those?
Would the runners be the same that are used for builds?
If this is successful, I would probably want to also do this for Ghidra, which runs through a full build with networking enabled to be able to generate a list of sources.
As far as how many times it can be run, There are no real limits on what an open source project can consume as far as Github Actions goes.
On the Flathub side, their CI is still required for merges to happen. I know of multiple projects using a similar setup when it comes to external updates.
The Flatpak builds themselves are still done on Flathub’s infrastructure. These actions are mainly for automated code updates, e.g. updating a manifest of generated-sources.json in this case.
Various projects from flathub ones to other apps have some forms of update workflows in place.
As I linked earlier, there is a section in the Flathub documentation for Github Actions being used on flathub org repositories: GitHub actions | Flathub Documentation
The only actions that are allowed are ones that are on that small list. Github published actions (actions/*) are allowed as well. I personally haven’t tried to use actions that are not on that list, so I am not sure if there is a block on them on the Github side.
Instead of running them hourly, you should run them only whenever there is an update to the application or when flathubbot opens a PR with the update.
Too many pushes and commits will overload the Flathub build infrastructure and those dependencies don’t need regenerating unless upstream lockfiles have changed.
Another option is to opt out of the global x-checker External Data Checker | Flathub Documentation and handle updates yourself using the create-pull-request action and flatpak-x-checker docker image.
That way you should be able to parse the manifest using jq or yq and check if the app version changed. If it changes, then you regenerate the cargo or node sources.
As long as you don’t overload Flathub build CI (buildbot) it’s fine. Flathub Github org doesn’t have any special limits other than what Github imposes.
I did something similar in my PR, it’ll check every hour (or could be loosened to day) and if no changes are detected it’ll skip other checks and nothing is done other than a quick curl or two.
If there is a change, a PR is opened and that should be the only churn that the buildbot has to deal with.
