feat: Serialize patches contained in .rvp files into JSON files

[brosssh]

Serialize the patches contained in every .rvp file for each release tag (dev, stable, latest) for each bundle. Store the resulting patches list in a JSON file, with suffix patches-list.json.

[Jman-Github]

Thanks for the PR! Before I merge I would like a few changes and questions answered.

1. Does this support more than one bundle URL? If it does great, but either way, I think it should pull the URLs from a TXT file instead of having to list each and every bundle in the Kotlin scripts. Each bundle URL would be on its own line in a TXT file located in the root directory of the repository. This makes it easier to update the list for when patch bundle repositories are removed or added to this repository and even automate the list to update when ever new repositories are added to the bundle-sources.json file (which is where I add repositories so the bundle updating workflow knows what repositories to check).
2. After the patches contained in each bundle are serialized to JSON, does each patch bundle gets it's own separate JSON file or do they all share one file? Ideally for organizational purposes and to follow the current structure of the repository I think each patch bundle should have it's own JSON file for the serialization of the patches contained inside. So for example the 1fexd patch bundle would have 3 JSON files named "1fexd-dev-patch-list", "1fexd-stable-patch-list" and "1fexd-latest-patch-list". Every other patch bundle in the repository would contain those same 3 files with the relevant naming inside their existing bundle folders.

Overall my goal with this PR would be having all the serialized patch lists in the JSON files printed in a separate README file which would have each bundle separated into their own collapsible section (which would be set to be open by default to allow users to search the file). I could most likely do this part myself, but any changes to your bundle parser and patch serializer you made (like the ones mentioned above) I would appreciate your assistance with to ensure I don't mess it up. Once again, thank you!

[brosssh]

Hello @Jman-Github,
I updated my code as per your requirements above, with a couple of adjustments.

The process will now loop over the bundle-patches folder, and process each folder found. It will read every files in the folder, and try to generated the patches file. The generated file will have structure:

{   
    "version": "v1.7.0-dev.1",
    "patches": [
        {
            "name": "Unlock Pro",
            "description": null,
            "use": true,
            "dependencies": [
            ],
            "compatiblePackages": {
                "com.calistree.calistree": [
                    "4.17.8"
                ]
            },
            "options": [
            ]
        },
        { ...
		}
	]
}

The version field is used to download the .rvp only if new changes are detected (aka version changed since last time).
The generated file is generated in the same folder as the other files, with file name {bundleName}-{releaseTag}-patches-list.json (ex. brosssh-dev-patches-list.json).

I have also already updated the CI flow. You can see the result of it running in my fork https://github.com/brosssh/ReVanced-Patch-Bundles. It also contains the generated files.

A current limitation is that this does not support old patches, the one which still uses integrations.

Let me know what you think of the current implementation.

[Jman-Github]

Hey @brosssh, thanks for all the effort and time your putting into this. I really appreciate it.

I love the adjustment you made of having the process read the patch bundle JSONs. Much better idea and eliminates the need for a separate file listing all the repositories. Much more efficient and clean.

After looking at your repository I see that the CI flow fails if there are no changes to commit on the "Commit new files" step. In my original CI flow I had it skip unnecessary steps if there weren't any changes detected/needing to be made and had it still pass as a successful run. Don't know if it's a better practice to just have the CI flow fail if there's nothing for the it to make changes too, but I'd prefer it to do the same thing my original CI flow did when no changes were being committed.

Also, let me know if this is pointless or impractical, but shouldn't the generated patch list JSON files print the patch lists in the same multi-line formatting you showed above in your message, instead of it being on all one line? I was thinking it would make it more human readable. Not sure if it would actually change anything for the better for a CI run reading those patch lists and printing them in a README.md file though.

[brosssh]

Fixed the CI flow, as well as added formatting to the generated JSON. The formatting is probably not really useful if you plan to generate a common README.md, but still is better to be consistent with the other JSONs.

[Jman-Github]

Alright, thank you. Everything is looking good. One last thing should be adjusted, and then I think its ready to merge (unless you think otherwise or have more to do). That one last thing is adjusting the CI job to only print the changed/updated bundle JSONs in the "updated_bundles" artifact and not listing any changed/updated patch list JSONs. The other artifact (changed_files) should be left as is. Its current output is fine, just the "updated_bundles" artifact needs a few tweaks. See the artifact for reference here.

[brosssh]

Fixed. To me it can be merged but keep in mind I didn't do anything related to the "frontend", I just made the process to generate the JSONs files, so that should be handled as well.

PS. This should be squash merged :)

[Jman-Github]

Alright thank you for your help. Not sure I am understanding what you mean by "I didn't do anything related to the 'frontend'". Before I merge I would appreciate some clarification on that.

[brosssh]

I just mean I didn't modify the current readme nor create a new one. All this does is creating the JSONs, but currently there is still no handy way to visualize patches.

[Jman-Github]

Oh okay, yeah I knew that. Im planning on doing the patch list in a README.md myself, unless you want to do it or have a better way to implement it. All I was going to do is a python script and GitHub action that reads the patch list JSONs and prints them in a new README file under their patch bundles name. It would only print the patch name, description, app package(s), and supported versions. The workflow would only run when a change is made to any of the patch list JSONs.

[brosssh]

Sounds good to me, I'll leave this to you if you don't mind, you'd probably be quicker since you've already done similar things. I'd be happy to help if you need anything :).

[Jman-Github]

Okay, thank you very much for the contribution!

Will be merging at some point today.