Add an option to skip patching if the version has already been patched

[amura11]

Support guidelines

• I've read the support guidelines

Description

Add an option, either globally or per application, that will skip patching an application if the version has already been patched. Since the output filename has the version in it a simple check before patching if the flag is on and the version is already patched skip that application.

Motivation

I want to build a docker container to run in unRAID that runs the application on a schedule so when a new version is ready for patching it gets downloaded, patched, and I get notified so I can update right away.

Additional Context

No response

[Nikhil Badyal]

If i understood correctly. You want to skip patching an app if it the same version of the app was patched in the past.

If yes, i see issues with this.

1. The builder itself is stateless, it doesn't retain the memory what it build in the previous run.
2. Multiple releases of patches/integration can support same version of the app. If I add support for such features we will miss new feature releases and bug fixes which Targets same version of the app

[amura11]

Yup that's correct and I see your points. I could see a workaround for 1 by checking the output directory for an existing APK with that version but I see what you mean about 2.

I'm not super familiar with the CLI tool so I'll need to do some digging but if the patches have dates/version you could store those along with the last app version patched to some kind of state file.

Eg.:

{
    "youtube": {
        "version": "1.2.3",
        "patches": [
            {"patch-1": "0.0.3"}, //If patches have versions
            {"patch-2": "2024-01-02"} //If patches have dates
        ]
    }
}

Then if the flag is on compare the app version and patch versions (or dates). Though this kind of approach would now add a kind of state to the build and I could understand not wanting that.

[IMXEren]

Hey @amura11, I assume that your main objective is to build patches on new patch releases. If so, maybe I could provide a valuable information on this.

I have implemented the update mechanism for the github builder using a python script for logics and github workflow for scheduling the run. So, let me explain how the update routine works: Example run -> https://github.com/IMXEren/rvx-builds/actions/runs/8680371157/job/23800767266

• Github Workflow runs on schedule and invokes the python script.

• Python script parses the .env file for the patch resource (PATCHES_JSON_DL). (If none, default ReVanced/revanced-patches is added as a resource).

• It then filters out non-github links. (As there is not an individual implementation to determine versions for other links)

• As GitHub provides an API to get releases data and release tag must always be unique, it's a good way to differentiate if the release is different. So, the script iterates over a list patches json links to generate another list of dict of valueable data like patch resource release link and it's tag name.

  [
    {
      "patches_json_dl": "https://github.com/revanced/revanced-patches/releases/latest",
      "tag_name": "v4.6.0"
    },
    {
      "patches_json_dl": "https://github.com/yt-advanced/rex-patches/releases/latest",
      "tag_name": "v2.220.10"
    }
  ]

• Now, an algorithm is used to check if that and locally stored previous patch release list is same or not. If it identifies it as an automatic update (i.e. no new resource dls were added; as that would be manually added and it's possible you could have also invoked the builder, hence no need to repatch), the builder is invoked using the GitHub API.

If you want you can checkout the source code here:

• update.yml
• check_updates.py

[Nikhil Badyal]

the patches have dates/version you could store those along with the last app version patched to some kind of state file.

Yes, Every time builder run it maintains a file(as of now file info is not getting used). But i think it will serve your purpose. See the file format here.

I could understand not wanting that.

Yes, It's better to keep the builder stateless and maybe write a external service which commands the builder to just build the apps when required.