r2northstar / verifiedmods Goto Github PK

Related to #5

Having the commit hash next to version and checksum would be useful to detect someone shifting around the tag that was used validate a previous version which could allow hiding commits if we only look at differential changes.

This would change

{
    "Fifty.mp_frostbite": {
        "DependencyPrefix": "Fifty-Frostbite",
        "Versions" : [
            { 
                "Version": "0.0.1",
                "Checksum": "8cf111c9ac2ab1521677769702e10be4db8d47c0eca16bda197aceb895cf2b5c"
            }
        ]
    }
}

to

{
    "Fifty.mp_frostbite": {
        "DependencyPrefix": "Fifty-Frostbite",
        "Versions" : [
            { 
                "Version": "0.0.1",
                "CommitHash": "446f6e2774206c6f6f6b20626568696e6420746865206375727461696e212121",
                "Checksum": "8cf111c9ac2ab1521677769702e10be4db8d47c0eca16bda197aceb895cf2b5c"
            }
        ]
    }
}

I'm not sure if we should make the key optional or not as maps might have an issue in general with being hosted on GitHub due to their file sizes.

A JSON schema is a JSON file that describes the structure of a JSON file.

Defining a JSON schema would allow us to automatically verify the structure of the mod.json and automatically throw an error in CI if someone PRs an incorrect JSON file ^^

See also https://json-schema.org/overview/what-is-jsonschema

When the verify_versions.py script fetches tags of a mod repository, it only accesses the first tag page (e.g. https://api.github.com/repos/{}/{}/tags), while tags resource is paginated (i.e. searched tag might not be on the first results page).

See #16 (comment) for pages example.

Having the GitHub repo linked in there would help with automations that compare Thunderstore package with GitHub repo to check for modifications etc

This would change

{
    "Fifty.mp_frostbite": {
        "DependencyPrefix": "Fifty-Frostbite",
        "Versions" : [
            { 
                "Version": "0.0.1",
                "Checksum": "8cf111c9ac2ab1521677769702e10be4db8d47c0eca16bda197aceb895cf2b5c"
            }
        ]
    }
}

to

{
    "Fifty.mp_frostbite": {
        "DependencyPrefix": "Fifty-Frostbite",
        "Repo": "https://github.com/some-user/some-repo",
        "Versions" : [
            { 
                "Version": "0.0.1",
                "Checksum": "8cf111c9ac2ab1521677769702e10be4db8d47c0eca16bda197aceb895cf2b5c"
            }
        ]
    }
}

I'm not sure if we should make the key optional or not as maps might have an issue in general with being hosted on GitHub due to their file sizes.

tcli uses DEFLATE as compression format, we should explicitely mention that in the documentation.

Related to R2Northstar/NorthstarLauncher#602

See R2Northstar/NorthstarLauncher#635

Currently, the CI of this repository assumes all mods are hosted on GitHub, which might not be the case in the future (thinking about GitLab rn).

Have CI

• compare provided commit hash against GitHub repo tag
• create a comment linking the tagged repo URL and Thunderstore download link
• extract Thunderstore zip to check for trivial zip bomb?
• ???

• better PR template (initial mod verification request, verified mod update, PR that's not mod verification) Not really doable, fancy templates only exist for issues cause GitHub...
• Assign people that can verify
• Actually verify Fifty.mp_frostbite v0.0.1
• Improve automations

Okay, before anyone gets into a hissy fit and calls this change "woke" or some BS, Imma let you know that for the majority of our repos, the default branch is called main.

So this should simply be done to bring it in line with the rest of our repos ^^

https://northstar.thunderstore.io/package/odds/s2space/

I believe s2space is the mod that sticks the most to our verification requirements.

(let's do #5, #6 and #7 first)

Both @Alystrasz and I have been committing using conventional commit messages, primarily out of habit

I'm wondering if we should actually enforce this for master branch so that all commit messages on master are formatted as conventional commits?
(Note that this would not affect commit messages in PR'd branches as those commits are squashed on merge anyway, meaning only the person merging the PR has to make sure the merged commit is formatted correctly.

Also for verification requests we would use our own tag called verify: or something ^^