Closed kikugie closed 2 months ago
Specifically, GHRelease
instance is created in the following way:
Since builder
is private there's no way to create an instance with /tags/$tag
added to the url.
On library's side it would be a good alternative to provide a method with an url parameter, but unfortunately its not available.
createRequest()
in GitHub
is also private, which makes creating a custom request more problematic.
Hi, great idea this isnt a use case I thought of! Definitely something I would like to support. Might be a little bit tricky to make sure that one project can create the release and the other uploads.
org.kohsuke.github is used, which is quite restrictive
Yes, I had a plan to move away from this an just make an api following the same pattern to CF and MR.
A work around for now would be to upload the other files as additional files from one project.
A work around for now would be to upload the other files as additional files from one project.
Well, that's exactly what is not possible in the setup I described. For example, I have a mod building for 1.19.4 and 1.20 with a multi-version setup. To publish, it first builds 1.19.4 versions and uploads it, then does so for 1.20. 1.20's build script is unaware of 1.19.4's files and vice versa. An alternative approach is to build and gather all assets and publish them together, which is less clean.
From testing I did, the second publish action failed to fetch the tag from gh api, although only in some cases. Fetching it and printing in debug worked fine, but getting the release failed.
A work around for now would be to upload the other files as additional files from one project.
Well, that's exactly what is not possible in the setup I described. For example, I have a mod building for 1.19.4 and 1.20 with a multi-version setup. To publish, it first builds 1.19.4 versions and uploads it, then does so for 1.20. 1.20's build script is unaware of 1.19.4's files and vice versa. An alternative approach is to build and gather all assets and publish them together, which is less clean.
Something like additionalFiles.from(project(":1.20.1").tasks.remapJar.archiveFile)
in theory should work. I used something similar to this here: https://github.com/TechReborn/TechReborn/blob/1.20/build.gradle#L374
I still agree that a proper soltuion is needed 👍
I'm running into this with my own multiversion project now, would love to see this implemented!
I'm running into this with my own multiversion project now, would love to see this implemented!
Found a solution/workaround, do def gh = publishMods.github(){}
and in a subprojects.afterEvaluate
block, do gh.configure { additionalFiles.add(...) }
Description
In the github action there should be an
append
parameter, which instead of creating a new release will upload files to existing one with the same tag. This can be done by uploading it to"$endpoint/repos/$owner/$repo/releases/tags/$tag"
url (instead of default"$endpoint/repos/$owner/$repo/releases"
).Motivation
Multi-loader and multi-version projects may run gradle independently for each subproject, isolating each release action. On Modrinth and Curseforge files can be filtered by game version or the loader, so isolation doesn't matter, but on Github it makes sense to group releases by mod version.
Research
For example, Breadmoirai's gradle plugin supports uploading to existing releases. Using it, files can be appended by enabling
allowUploadToExisting
parameter. Due to an issue with the plugindraft
parameter has to be set totrue
for all releases after the first one.In the current plugin org.kohsuke.github is used, which is quite restrictive, hardcoding the final upload url and not providing custom options. I haven't found a workaround for it without making manual requests yet.