search

flathub / com.obsproject.Studio

This repository is no longer used to build OBS. Issues should be reported at https://github.com/obsproject/obs-studio
https://github.com/obsproject/obs-studio
29 stars 21 forks source link

Decide the flow of upstream releases #136

Open GeorgesStavracas opened 3 years ago

GeorgesStavracas commented 3 years ago

I see two options to move this forward.

1. Direct Push from Github

See https://github.com/flathub/flathub/issues/2320

The first option would be Github → Flathub, where we extend the Flatpak workflow of obsproject/obs-studio by publishing builds when Github releases are maded. Each Github release has a corresponding tag. All releases should be routed to Flathub Beta, but only releases whose tags do not have the -rc* suffix should go to Flathub stable.

The downside is that it uses a relatively untested path. AFAIK only Firefox currently does this. Also, because it uses a token to authenticate the push, this may be a potential security issue.

2. Parallel Management in Flathub

The second option is manage it entirely on Flathub side. This could include adding the extra data checker to monitor the OBS Studio repository for new tags.

The downside is that two Flatpak manifests for OBS Studio will co-exist, one in Flathub and one in OBS Studio. The extra-data checker might need to be adjusted to check the tag suffix, and decide whether to open the merge request against master or beta. It also means that the Flathub manifest needs to be reviewed for every release.

WizardCM commented 3 years ago

For 1), it's worth noting that sometimes a commit will be tagged, and an issue will be found before it's turned into a Release using GitHub's flow. It may be more suitable to use the GH Actions Release trigger. This'll still provide the commit hash and the relevant tag, but should lower the potential for bad Flathub releases.

Personally I think with enough testing, 1) is the most viable and safest. It may occasionally need manual cleanup (I don't know what this would entail or when this could occur), but should generally be a lower management burden.

GeorgesStavracas commented 3 years ago

Thanks! I wasn't aware of the release trigger, but it indeed seems like a better option. Updated the description