Known addons can update without making PR

[luttje]

Hi there, hope you are all well!

The Garry's Mod addon was last updated through a PR at LLS-Addons on October 3rd 2024. That was version v0002. Since then some new versions have been published to our library repo, however at the time of writing I have yet to make a PR to merge them into LLS-Addons.

Despite not having had a PR (and thus no manual validation by @carsakiller) the newer versions show up and can be switched to:

I remember reading somewhere that the manual process of updating an addon through PR is a sort of security/sanity check. For that reason I don't believe this is intentional

Note that selecting the 'latest' version will still result in the LLS-Addons version to be chosen (for gmod: v0002)

Details

• Using VSCode Extension 3.13.5
• Windows 10
• git version 2.44.0.windows.1
• Webvue version v0.2.0

[2025-01-11 12:03:47] |  VERBOSE  |       Command      | Executing "setVersion" ({"command":"setVersion","data":{"name":"garrysmod","version":"v0006"}})

[carsakiller]

Hmm. I did not consider that when adding the version swapping. It indeed just pulls tags from the source repo (as they would not exist on LLS-Addons, as far as I am aware), and then allows checking them out.

While the PRs are intended to increase security, quality, and catch simple errors. I actually feel a little more inclined to allow this. I still worry about untrusted code execution from plugins, but for authors that have already been reviewed and merged in… this could make it faster and easier for them to update.

I'd like to hear some opinions from others on how they feel about it.

The other option would probably be reworking the version selecting so you can only check out commits for each addon that exist in the LLS-Addons git history, meaning they would have been vetted. That then also means that it wouldn't be nice tag names, but commit hashes for the version selector. Unless, maybe, I get the commits and then search around for which tags, if any, are on those commits in the source repo.

[luttje]

Perhaps after a PR has been accepted a workflow in LLS-Addons could fetch the tags available up until that point and put them in the metadata. Then vscode-lua can use those to list which tags are available and switch only to those.

[TIMONz1535]

Do I understand correctly that plugins will work only if the user has enabled it in the workspace/user settings via Lua.runtime.plugin? So if the user just installed the addon, the plugin won't work, right?

Anyway I understand that plugins can be very dangerous. Perhaps I would like to be able to enable a specific "beta version", if I have enabled "show beta versions in the list" for example. Or maybe just by specify the tag/git revison manually. Then I will be shown a dialog warning window where I take on possible risks.

Probably in the generalized case we can specify third-party URL for the addon with the tag/revision/HEAD of repository. This is done by some tools that do not want to approve all existing addons, but only popular/large ones. Thus, the user can specify his own repository himself.

VRChat Creator Companion
curated + betas + community repos (with versions) + user local folders
but no auto-updates, because these are packages for your unity projects.

this checks that the repository contains json info and it is a valid addon, then it shows the warning