-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix "Java CD" workflow responsible for automated publishing #19
Conversation
Thank you so much! I'll merge it in and try it out! |
Ah yeah, I keep running into an issue where the CurseForge ID isn't found, see the latest publish workflow run |
First of all, I really need to add a proper debug mode to Secondly, I believe |
Ah ok, thanks. That sounds likely |
Let's go, that worked! I'm writing up my thoughts on merged JARs in the issue I opened in |
Yay! It somewhat worked, finally :D By the way, that very poorly worded error you received from GitHub is there because of: permissions:
contents: read
permissions:
contents: write Sorry for overlooking this when I made the PR! |
Ahh, that's all good. I'll add that in and make a few extra workflows so I can publish to specific platforms separately from each other. |
This PR fixes (or at least it should fix) your publishing workflow.
A dry run of
mc-publish
results in the following output:As you can see, your mod's metadata is read correctly, and all the necessary jars are selected for publication in the expected order (i.e.,
noisium-merged-2.0.0+mc1.20.x.jar
is the primary file, and the others are secondary).Once again, note that
mc-publish
only reads one metadata file per jar. This decision was made under the assumption, which was reasonable at the time, that nobody would merge mods for different mod loaders into a single binary. Thus, given that my beloved Fabric has a completely unbiased higher priority internally, onlyfabric.mod.json
is read. So, feel free to clean upmods.toml
from duplicate entries if you feel like it :)See Kir-Antipov/mc-publish#114.