Enforcing pull request workflow and green CI status of PRs

This change reduces a lot the amount of automation one can achieve in its deployment, and requires more manual interventions and human time.
This leads to increased costs for maintaining a flatpak package.

As well for rejecting the flathub.json setting, instead of having that configurable by the package maintainer, you will instead have to process issues on github. This again will increase your costs in human time for maintaining flathub, and introduce boring tasks which will reduce your motivation.

I don’t understand what problem your are trying to fix with this change.

No one cares if the package’s history is full of trials and error. This is not a bad thing to have history and I don’t think that so many people read the build script.

Even if a user makes a pull request it does still run the tests on the buildbot, and actually it’ll run them twice: once for the PR and once after the merge, which will lead to increased costs for your infrastructure.

I think a workflow with forced PRs can work nicely without a lot of human interaction. You can use a develop branch for your development between releases and create a PR from develop to master whenever you want a test build. What you can do to automate updates is create a Github action that checks upstream for new versions, updates your manifest and commits the change to develop. The only missing piece is the ability to automatically create PRs from such a Github action.

@barthalion There is a Github action for creating PRs that seems to be widely used, but it is not allowed to run in flathub repos. Allowing such an action would help developers automating the update process as outlined above.

Thanks, added it to the list of allowed actions.

2 Likes