Open dgcampea opened 3 years ago
@wjt has added an f-e-d-c GH workflow to Endless OS Chrome flatpak. Maybe we can turn that workflow into a reusable action?
I believe this is available now through https://github.com/flathub/actions ?
@daenney No, the actions you linked are internal to flathub. The f-e-d-c action checks all apps on flathub instead of just one in you repo.
The checker for Endless Chrome looks very similar to this one that @gasinvein suggested to use in EasyEffects. https://github.com/gasinvein/org.winehq.Wine/blob/branch/staging/.github/workflows/update.yml
For EasyEffects in Flathub, why did the permission need to be changed for the workflow to work? Why can’t the action be allowed to run anywhere on github by default?
Why can’t the action be allowed to run anywhere on github by default?
It's the other way round - flathub org allows to run only selected actions in the org-owned repos.
FYI I started throwing together an action, i.e. something that could be on github marketplace. The current state of the files is here (warning needs cleanup).
One of the things I initially sort of tried was to make it generic, such that in theory both an individual and a github org (i.e. Flathub's actions) could use it. Is that even worth the effort to add support for github orgs? Long-term do you think flathub should keep an org-wide workflow?
As far as I can tell individual repos seems to work (at least at smoketest level). When ready would an action be PR material for here?
Are there plans to enable the flatpak-extrernal-data-checker for the entire Flathub org or should we enable it per repo?
The actions that are currently enabled appears to mostly be broken: https://github.com/flathub/io.github.achetagames.epic_asset_manager/runs/5464917061?check_suite_focus=true
And there are a lot of them:
We're looking at enabling the checker for all KDE repositories so we are interested in this work.
Many Flathub repos today use the currently existing Flathub wide fedc instance, which does not require an action file in the individual repo. Eg Chromium. The action is stored in https://github.com/flathub/actions (but that’s not relevant for the app). Not much needs to be done besides follow the readme here and add the metadata (and test it).
But if you do not want the Flathub checker you can make a custom workflow file (like what some of your links try to do). A working example can be done like in wine listed above. Perhaps a fancy GitHub marketplace action (with more user friendly control?) could exist in the future too.
Oh, thanks, I hadn't realized that there was a global one already running. We will give it a try.
But this still means that we should remove the per-repo actions right?
Well, there are use cases for a per repo action. E.g. the Flathub checker only checks the default branch of the Flathub repo. Also, unsafe features like custom checkers could only be allowed for per repo actions (but that doesn’t exist quite yet AFAIK).
Indeed if you can use the Flathub checker it makes sense to remove the unneeded/redundant files.
On a complete tangent, there is a handy GNOME checker which offers easy syntax for checking GNOME tarballs. Would a similar checker be useful for KDE? It could reduce the tedious work to add x-checker-data to many KDE modules. At least, the syntax is simpler.
Good idea, we will take a look
Allows some automation for manifests not hosted on Flathub.