search

Kir-Antipov / mc-publish

🚀 Your one-stop GitHub Action for seamless Minecraft project publication across various platforms.
MIT License
228 stars 20 forks source link

Add support for plugins #23

Open Andre601 opened 2 years ago

Andre601 commented 2 years ago

I posted the info already in #22 but decided to actually make this issue for better tracking.

Support to obtain values from a Spigot, BungeeCord or Velocity plugin to auto-fill values such as version and also the Modrinth/CurseForge ID would be nice to have here.

Both Spigot-based servers and BungeeCord-based proxies (including most forks of either) use a plugin.yml to obtain and use data such as the path to the main class, plugin name or version. In the case of BungeeCord does also a bungee.yml file exist that can be used. It's basically there to allow hybrid plugins that should work on server and proxy and is prioritized by the proxy when both files are present.

Neither Spigot nor BungeeCord care if there are values in the YAML file that aren't used by them, as long as at least the required values are there, which means there is no need for a "custom" section or similar.

One note tho: Paper, a very popular fork of Spigot that adds API and Performance improvements, is currently working on a dedicated paper-plugin.yml, which, similar to a bungee.yml on a Bungee proxy, would allow defining different values for the plugin, so maybe keep that in mind for the future. A pull request discussing this feature is here: https://github.com/PaperMC/Paper/pull/8108

Another proxy that should be supported is Velocity. It has a different approach. It uses a velocity-plugin.json which is created in 2 ways:

  1. Through a @Plugin annotation that processes the provided inputs at compile to create the JSON. This means that support for this kind of plugin could be more difficult to achieve unless Velocity allows somehow to apply custom values through their Annotation-processing.
  2. Through manually creating the JSON file. This is the easier approach for support at the cost of the dev having to make the file themself.

For Velocity, I cannot say if it also ignores any extra keys/inputs in the JSON file or would give errors/exceptions when finding them. We have to figure this out eventually.

This is the info I'm able to provide here. I, unfortunately, do not know enough JS and TS to implement those myself.

WiIIiam278 commented 2 years ago

+1 - Now that modrinth supports plugins, the use cases of this have been expanded quite significantly. It'd be nice if the documentation could be updated a little to support this (e.g. with "loaders", where modrinth now accepts 'spigot', 'bukkit', 'sponge' and 'purpur', et al.)

Kir-Antipov commented 2 years ago

Is there a way to tell which loader a plugin that contains a plugin.yml definition targets?

Also, which of these values [bukkit, bungeecord, fabric, forge, liteloader, minecraft, modloader, paper, purpur, quilt, rift, spigot, sponge, velocity, waterfall] represent plugins?

Andre601 commented 2 years ago

Is there a way to tell which loader a plugin that contains a plugin.yml definition targets?

Unfortunately no. There are settings that only exist for a server (afaik api-version is one or the libraries one) but they are not required and could therefore be missing. So the only way would be the bungee.yml and plugin.yml distinction which isn't that clear. Only other way could be to check the project's pom.xml/build.gradle to see what dependencies are used, but this would most likely be unreliable too.

Also, which of these values [bukkit, bungeecord, fabric, forge, liteloader, minecraft, modloader, paper, purpur, quilt, rift, spigot, sponge, velocity, waterfall] represent plugins?

Kir-Antipov commented 2 years ago

Unfortunately no

Alright, then this information should be specified by a user in their whatever-the-file-name-is.yml, for example:

mc-publish:
  loaders: [bungeecord, waterfall]

Bukkit [...] Waterfall

Oh, so literally everything except the things I'm familiar with :D That's quite a list. Ok, that's what I need from you, folks, in order to implement the requested support of new formats, because I have no points of contact with all these plugins of yours, - for every loader in this list (from Bukkit to Waterfall) make a pull request, please, containing a configuration file fulfilling the following conditions:

1) A file should be put to test/content/{platform}/{configuration-file} (e.g., test/content/bungeecord/bungee.yml) 2) It should contain an identifier of the plugin (if applicable) 3) It should contain a name of the plugin (if applicable) 4) It should contain a version of the plugin (if applicable) 5) It should contain a list of the supported loaders (for those cases when it is not possible to automatically identify them based on the name of the configuration file itself) 6) It should contain a custom mc-publish entry (if applicable), e.g.,

   mc-publish:
     modrinth: AAAA

7) It should contain at least one required dependency (if applicable; but I think plugins are able to depend on other plugins for sure) 8) It should contain at least one optional dependency (if applicable; soft dependencies should be possible too, I'm sure) 9) It should contain at least one included/embedded dependency (if applicable) 10) It should contain at least one conflicting "dependency" (if applicable) 11) It should contain at least one breaking "dependency" (if applicable) 12) It should contain at least one suggested dependency (if applicable) 13) At least one of these dependency should have a custom metadata attached to it (if applicable), e.g.,

   id: dependency-id
   mc-publish:
     modrinth: AAAA

14) It goes without saying, but a provided configuration file should be an absolutely valid example that can be processed by the specified loader, so, please, make sure that custom metadata does not break anything

Examples of all the conditions above can be seen in any file that already exists in the test/content/ folder.

Andre601 commented 2 years ago

Should the files be in separate PRs or is one PR for all files I know okay?

Kir-Antipov commented 2 years ago

It would be nice to have different PR's, because I will still need to tweak them

Andre601 commented 2 years ago

There we go. Made the PRs.

I sadly don't know how Sponge plugins are structured, so someone else has to provide a valid example

WiIIiam278 commented 2 years ago

Sponge APIv8+ plugins define metadata through a sponge_plugins.json file in the META-INF directory (META-INF/sponge_plugins.json). This can be included:

Sponge APIv7 previously defined information similarly in a mcmods.info file. Sponge implementations are quite API dependent and iirc not very forwards/backwards compatible friendly (in general). I think, broadly, support for automatically pulling this information from sponge might be a little complicated at best and kind of impossible at worst.

I'd also like to preliminarily draw attention to the new specification in draft for paper-plugin.ymls. Not something to worry about just yet, but its' likely that paper will soon have its' own spec for defining plugins (useful for plugin developers who want to target both spigot and paper). (I've just realised that that's actually Andre's paper PR, haha, nice stuff.)

Kir-Antipov commented 2 years ago

@WiIIiam278, would be perfect to see this in a from of PR ;)

srnyx commented 1 year ago

Along with plugin support, could support be added to update plugins on Polymart, Spigot, and Bukkit? Gonna be honest, I've never used MC Publish as I've not had a use for it yet. So please take everything I say with that in mind lmao

Andre601 commented 1 year ago

Bukkit, if you mean dev.bukkit.org, is just curseforge. All plugins listed there can also be found on cf from what I know, so automaton is possible through the cf api.

Kir-Antipov commented 1 year ago

mc-publish consists of 2 parts:

1) Reading your asset's metadata (if possible/needed) 2) Publishing it

If something does not or cannot follow this simple formula, it lies outside of the scope of this project. Therefore, Spigot and BuiltByBit support won't be implemented, at least the way you describe it. Polymart may become a part of mc-publish in the future, but it is pretty low priority and would definitely not be present in the upcoming v4.0. On the bright side, Bukkit support is already here, as mentioned by Andre601.

Most of the things described require conversion, not publishing. Thinking out loud, but I may create a separate action for cases like that (e.g. mc-convert. Yeah, I know, my creative genius is at its peak today), since I'm sick of manually editing project descriptions on Modrinth and CurseForge because they use different Markdown engines

srnyx commented 1 year ago

Most of the things described require conversion, not publishing. Thinking out loud, but I may create a separate action for cases like that (e.g. mc-convert. Yeah, I know, my creative genius is at its peak today), since I'm sick of manually editing project descriptions on Modrinth and CurseForge because they use different Markdown engines

Honestly, whatever you do to make it so that I don't have to spend an hour releasing a plugin update, I'll gladly use!

Also, I'd love for the README.md and overall the entire repository to be updated to have information for all types of projects, not just mods (I know it's practically the same, but it makes me a lot more sure that I'm doing the right stuff when it doesn't say it's just for mods).

Kir-Antipov commented 1 year ago

Also, I'd love for the README.md and overall the entire repository to be updated to have information for all types of projects

When I released this project, it was focused solely on publishing Fabric mods to Modrinth, CurseForge, and GitHub. Then I implemented support for Forge mods. A little bit later - support for Quilt mods. And now it's time for mc-publish to expand once again and embrace other types of projects, not just mods. This is the theme of upcoming v4.0. So, of course all information will be updated, don't you worry :)

srnyx commented 1 year ago

When I released this project, it was focused solely on publishing Fabric mods to Modrinth, CurseForge, and GitHub. Then I implemented support for Forge mods. A little bit later - support for Quilt mods. And now it's time for mc-publish to expand once again and embrace other types of projects, not just mods. This is the theme of upcoming v4.0. So, of course all information will be updated, don't you worry :)

I can't wait! 👀 Let me know if there's anything I (maybe others too) can do to help 😄 (although I assume it's just a bunch of Typescript programming, which I've got no experience with 😬)

WiIIiam278 commented 1 year ago

+1 for Polymart support! I'd love to be able to do CI on nightly builds there with some of my stuff that I can't use Modrinth for. Appreciate all the work you do, with how fragmented the Minecraft server/client modding scene is in terms of "places to go to get XYZ", there's a solid argument that conceptually simple things like this GH action go the furthest in improving unity among the community. Srnyx is bang on -- it really can take an hour to push out a release with all these different marketplaces and their formatting. Exciting to see plans for v4 and like the ideas for cross-platform markup conversion :)

domiehomie commented 1 year ago

Adding to this, support for the upcoming plugin repository Hangar would be a great feature to add when plugin support gets added.

I feel like because they only support plugins though, and because they still haven't released yet, it may be better to wait with this until the full plugin/resourcepack support is a thing, to make implementing this feature easier. I would be happy to add it by that time :)

Andre601 commented 1 year ago

From what I understand is the API accessible for everyone right now, so initial support (With later expansion if needed) would be doable.

Current API docs: https://hangar.papermc.io/api-docs

Kir-Antipov commented 1 year ago

Adding to this, support for the upcoming plugin repository Hangar would be a great feature to add when plugin support gets added.

I'm up for it, but yeah, I think this Hangar of yours should be fully released before we add support for it.

Andre601 commented 1 year ago

I'm up for it, but yeah, I think this Hangar of yours should be fully released before we add support for it.

I agree to an extend. While it makes sense to wait for a full release, development on that project has been extremely slow for various reasons. And I feel like that the required backend APIs such as the release one are stable enough here for an update. If those people provide proper Rest API, then their current version should stay supported for a while, even after making changes... If not, then we honestly can only blame them for exposing an API while not being ready... 🤷‍♂️

domiehomie commented 1 year ago

I'm up for it, but yeah, I think this Hangar of yours should be fully released before we add support for it.

I agree to an extend. While it makes sense to wait for a full release, development on that project has been extremely slow for various reasons. And I feel like that the required backend APIs such as the release one are stable enough here for an update. If those people provide proper Rest API, then their current version should stay supported for a while, even after making changes... If not, then we honestly can only blame them for exposing an API while not being ready... 🤷‍♂️

I feel like it not being fully released yet may lead to things like undocumented behavior and an increase in downtime compared to a production product. This is probably going to lead to errors that will make using this project more clunky. Because of that, it's probably better to just wait.

Andre601 commented 1 year ago

I'm up for it, but yeah, I think this Hangar of yours should be fully released before we add support for it.

Would it be possible to still work on it now instead of waiting? It doesn't need to be released at that point, but have it as a separate branch, so that we could use the Commit SHA instead of a version to use the action.

Supporting Hangar as of right now is a gigantic pain in the back as I need to do one of the following:

I know it's work and I appreciate the effort you put into this thing so far. And if I could I would help you out here, but I have no knowledge with this code language. But having Hangar supported - even if only as a separate, unmerged branch right now - would help me and probably so many others to automate this site...

Also, as mentioned before are they providing a versioned REST-API, meaning that unless they say "F*ck versioning" should breaking changes to their API result in a separate version path and bump, while the old one remains supported (when technically possible).

srnyx commented 1 year ago

I think this Hangar of yours should be fully released before we add support for it.

It's in Open Beta now so several people are wanting to use MC Publish for it now. Just letting you know in case it changes the status of this issue!

Kir-Antipov commented 1 year ago

Currently the main goal is to finish v4.0 before v3.2 becomes unusable because of Node12 deprecation. So, to put it simply, if I'll have time to look into this - I might do that

WiIIiam278 commented 1 year ago

I started work (extremely basic and unfinished) on support for publishing to hangar:

https://github.com/WiIIiam278/mc-publish/tree/hangar

A few things to work out, namely due to how hangar handles having multiple per-platform files, but if (that's quite a big if!) I can get it going properly I might PR. I'm not really that experienced with TS/custom actions development, so not really planning on touching stuff like upgrading node, etc, where I can't help it :) feel free to use my work if it helps (or feel free to avoid it like the plague otherwise!)

edit: pull request