Options for making a gramps.flatpak associated with a PR available for others to test?

[OzarkShepherd]

Github only allows 25MB archives to be attached to a PR. The PR I just submitted has a 44 MB archive, so it is too big. I can think of a couple options.

1. maybe accept a pull request into a new branch of gramps-project/flatpak (perhaps with a pull number and username?) so that a workflow can be run. This would demonstrate that the manifest does compile, and it can make an archive available for everyone associated with gramps-project/flatpak to download and test for themselves.
2. We can copy and paste the PR manifest into a new branch in our own private github fork to run the workflow

Any thoughts?

[jralls]

Are you trying to attach a flatpak of your PR as a tarball? That's not a great way to go because it's manual--the PR writer has to create the flatpak build, tar it up, and attach it to the PR--and it requires a bit of faith on the part of potential testers that it isn't some trojan. Better to create a github action to build a flatpak and save the result as an artifact that testers can download. That automates the process so that it happens to every PR, gets around the attachment size limitation, and provides a transparent process executed by a trusted environment to create the flatpak so that potential testers can be sure that it's not hiding something malicious.

[OzarkShepherd]

Is there another way to use the existing github action other than Option 1 for every PR?

[jralls]

I guess I don't understand what you want to do or even whether you're concerned about PRs on this repo or on the Gramps program one.

[OzarkShepherd]

Perhaps the misunderstanding is in the nature of this repository. There are no source files to test when a PR is made in this repository. This repository is actually for the script used by flatpak-builder to make what could be described as an installation file that will work on any linux computer regardless of which distribution it uses. That way, flathub can review every script for security, and then flathub admins can compile the scripts on flathub's own servers to make the install file that users use. So this is great for providing a secure installation file that will work on any linux computer, but the difficulty is in testing someone else's script before merging their PR to the gramps-project/flatpak repo. The script has to be run on a computer somewhere to compile the actual installation file before the resulting installation file can be tested. Here is the current script (manifest in flatpak terminology) https://github.com/gramps-project/flatpak/blob/main/org.gramps_project.Gramps.yml

The github action workflow for this repository is at https://github.com/gramps-project/flatpak/blob/main/.github/workflows/main.yml
However, the way this workflow is set up right now, you have to go into "Actions", select "CreateFlatpak" under workflows, and then select a branch. I do not know how to make Github Actions compile a PR that has not been made into a branch, and I can not access installation files (or archive in Github Action terms) compiled on someone else's repository. But without testing the installation file from running the script, there is no good way to merge PR's in this flatpak repository without the risk of messing things up.

Preferably, the ideal solution would be a way to use Github Actions to compile a script in this repository for any PR so that a working installation file can be made for testing. Thus my workaround idea about making a new branch on this repository for every PR before merging with main, so that the installation file can be made available for everyone.

Even better, would be a modification or new workflow that will compile scripts for new PR's without the necessity for a making a branch to run the current script. However, I do not currently know how to do that, and I have health problems right now that prevent me from sitting for very long. So I can't make the workflow right now.

What I did for PR #35 here was to make a new branch on my own fork of gramps-project/flatpak and then paste their script/manifest into it so that I could compile his manifest for testing. It does work, but I do not see it as an ideal solution for everyone who wants to test PR's (including others who want to test my PR's).

Another solution that I dislike even more is to copy the manifest into a directory on my own computer, and then open terminal in that directory to give the manual command to compile the manifest on my own computer. It takes up my home bandwidth, my computer's processing power, and is a potential risk to my computer. Using a VM would reduce the risk, but that uses up even more processing power to compile a manifest within a VM.

[jralls]

I know about flatpaks.

Preferably, the ideal solution would be a way to use Github Actions to compile a script in this repository for any PR so that a working installation file can be made for testing. Thus my workaround idea about making a new branch on this repository for every PR before merging with main, so that the installation file can be made available for everyone.

Assuming that you mean PRs for gramps, the correct solution is an action on each of those repositories that triggers on flatpak. That should be pretty straightforward, you can extend the action you wrote here to retrieve org.gramps_project.Gramps.yml and org.gramps_project.Gramps.metainfo.xml into the workspace before running flatpak-builder. You'll need to make the Gramps section module reference and write a shell script to generate the corresponding module so that it points at the PR branch. You could extend it or have a different one for releases where you feed it the tarball name and sha256.

[OzarkShepherd]

No, this repository has nothing to do with any PR at gramps-project/gramps. The PR's at gramps-project/gramps have nothing to do with the manifests here at gramps-project/flatpak. The gramps-project/flatpak scripts (yml manifests) only use releases from gramps-project/gramps. Therefore the PR's from gramps-project/gramps are irrelevant to PR's in gramps-project/flatpak. That is why I tried to explain the flatpak process to you, because you've mentioned gramps-project/gramps PR's in two responses and that is off-topic. The PR's I am discussing are at https://github.com/gramps-project/flatpak/pulls and I want a way to make a gramps.flatpak installation file from each PR at https://github.com/gramps-project/flatpak/pulls so that the installation file can be tested. Since you seem to be coming from a developer viewpoint while I am coming from a script viewpoint, perhaps I do not know the right terminology to get you to understand the issue here.

[jralls]

If that's all you want to do you're over-complicating the problem. Maybe

I do not know how to make Github Actions compile a PR that has not been made into a branch,

Is the source of the problem. It's a non-problem because github doesn't know how to make a PR without a branch. It doesn't matter that the branch lives in the submitter's repo, when in PR context github will still run the action in this repo's context so the job results including any artifacts will be accessible from the PR's conversation page.

All you need to do is to add pull-request to the on: statement in main.yml.

[OzarkShepherd]

Thank you, the workflow change to work on pull requests is included in the bug fix I just put up. #38
In the past I also tried to figure out how to modify the Github Action workflow make a gramps.flatpak for release. My intent was to it run manually from Github Actions, but I couldn't figure out a satisfactory workflow. If you know how to manually run a workflow to create a gramps.flatpak archive with sha256sum for releases at https://github.com/gramps-project/flatpak would you reply with the code (or make a PR with the workflow)?

[jralls]

Run a workflow manually.

I don't have time to do that for you. A workflow just issues shell commands so just add a a step with whatever commands you need, but I don't see what that's got to do with releasing on flathub.